
RFC 7858: DNS over TLS (2016) - walrus01
https://tools.ietf.org/html/rfc7858
======
niftich
This RFC is from 2016, and isn't breaking news, so per HN practice, title
should probably have (2016).

However, there's a March 2018 RFC 8310: _Usage Profiles for DNS over TLS and
DNS over DTLS_ [1] that describes some privacy implications, deployment
scenarios, and DNS authentication mechanisms to be used with the new
transports.

[1] [https://tools.ietf.org/html/rfc8310](https://tools.ietf.org/html/rfc8310)

~~~
gnode
It seems to me that neither TLS or DTLS are appropriate transports for DNS.
Both are connection oriented transports, with DTLS simply allowing that
connection to be lossy.

To maintain the performance of DNS, you'd want a connectionless protocol.
Although I'm not sure whether perfect forward security would be possible
without adding a round-trip.

~~~
fanf2
DNS can work very well over TCP and TLS. It avoids most head-of-line blocking
problems, because responses are usually small (a few KB), and they can be
returned out-of-order. It's still relatively new for servers to implement DNS-
over-TCP well (i.e. handling pipelined queries concurrently, and returning
responses out-of-order) - you need BIND 9.11 or `dnsdist`. I did some brief
testing yesterday, and in most cases TCP is as fast as UDP or faster. I was
using a client based on `adns` which keeps one persistent TCP connection open.

    
    
        Unbound 1.6.0 TCP 8s
        Unbound 1.6.0 UDP 0.4s
        BIND 9.11 TCP 0.5s
        BIND 9.11 UDP 0.5s
        BIND 9.10 TCP 3s
        BIND 9.10 UDP 0.5s
        1.1.1.1 TCP 0.5s
        1.1.1.1 UDP 0.4s
        8.8.8.8 TCP 5s # drops connection after 60 queries
        8.8.8.8 UDP 220s # it hates me
        9.9.9.9 TCP 1s
        9.9.9.9 UDP 3s
        64.6.64.6 TCP 0.5s
        64.6.64.6 UDP 0.5s
    

[https://www.ietf.org/mail-archive/web/dns-
privacy/current/ms...](https://www.ietf.org/mail-archive/web/dns-
privacy/current/msg01935.html)

~~~
gnode
I'm aware that this is the case once the connection is established. What I was
referring to was the latency of TCP and TLS connection establishment,
involving multiple round trips. Maintaining a persistent connection introduces
the problem of requiring the DNS server maintain state for each client.

------
cmurf
OK so which is more likely to play nice with constantly changing wireless
connections? DNS-over-TLS, DNS-over-HTTPS, or DNSSEC? I notice that out of the
box, Windows and macOS and Fedora all just defer to the DNS servers that are
assigned by DHCP, which come from the local AP. So I'm pretty much stuck, out
of the box, with AP specific DNS policy.

~~~
angrygoat
I've been using dnscrypt-proxy to access 1.1.1.1 using DNS-over-HTTPS for over
a week. Absolutely no problems so far switching between wireless connections;
writing this sat in a pub, tethered to my iPhone.

Not sure how I'll go with captive portals that rely on DNS hijacking, but
worst case I just switch to using their DNS servers for a brief period.

~~~
linsomniac
For a decade or more I always ran all my traffic through a VPN, and ran into
problems with captive portals. The way I solved it was that I would let DHCP
update my resolv.conf file, and then my VPN "up" script would overwrite
resolv.conf to use localhost as the name server. Sometimes I would have to
open a browser and go to an IP address in the URL bar to get the redirect.
This all worked out pretty well, only maybe once a quarter did I have to go in
and manually resolve some captive portal issues.

------
StavrosK
In case anyone is curious (like I was) about exactly how DNS-over-HTTPS works,
here's how:

[https://1.1.1.1/dns-
query?name=stavros.io&type=A&ct=applicat...](https://1.1.1.1/dns-
query?name=stavros.io&type=A&ct=application/dns-json)

Yep, it's (unsurprisingly) just an HTTP query.

~~~
aorth
This submission is about DNS over TLS, which is a ratified standard. You're
talking about DNS over HTTPS, which is super cool, but not yet a standard. :)

~~~
StavrosK
Yes, sorry, I should have clarified. I just remembered DNS-over-HTTPS because
of this article and looked into how it worked, so I thought I'd show others in
case someone was also curious.

------
gumby
I assume these still let your provider guess what TLDs you connect to by
looking where you connect. Not sure how bad a channel that is.

At least you'll have a better idea that you are getting authoritative
responses.

~~~
kuschku
For authoritative responses, DNSSEC exists.

And your provider can still find out what you connect to through SNI.

------
davidlt
Yesterday I decided to configure unbound on fresh Fedora 28 Beta install and
configure it to use DNS-over-TLS to Cloudflare and Quad9. unbound runs as
local recursive resolver. Within a laptop it's decrypted, but all outside
communications are over TLS (checked with wireshark). The 1st query for
unknown domain is slow, ~300-1000 ms, but afterwards it always report 0ms.
unbound in background should automatically update those record in the cache.
So far works with no problems noticed.

------
krylon
Stupid question: What do I need to do to use DNS-over-TLS? I am running a
recursive resolver in my home network (BIND9), so if that is a requirement, it
is not a problem.

EDIT: I misunderstood; I though this would encrypt communication between
resolvers and authoritative nameservers, too. :(

~~~
BuildTheRobots
Your recursive resolver is still going off over the internet and querying
(root) DNS entries in clear text. My understanding is that this would wrap it
in TLS to stop your ISP (or coffee shop) either spying on what sites you're
resolving (read visiting) or even man-in-the-middling and re-writing your DNS
responses.

~~~
bpicolo
mitm seems like the most important bit. They'll know what sites you visit
regardless when you actually fire off a request to the site, yeah?

~~~
cat199
DNSSEC already solves MITM if it is actually adopted by the domain being
queried..

------
riobard
Is there any resolver supporting out-of-order pipelined DNS requests over a
persistent TCP/TLS connection?

~~~
aplorbust
Not sure. However theres various endpoints offering "dns looking glass"
service that allow pipelined HTTP/1.1 queries.1

With this "DNS over HTTPS", given a page of HTML containing pointers to
various domains, using a simple script one can filter out all the domainnames
it contains, format them into HTTP requests, send them to the "dns-lg"
endpoint _over a single connection_ , parse the response and append the
answers to /etc/hosts or a local authoritative zonefile. Then one can browse
the page, including following any remote URLs without having to do any DNS
lookups.

1 For example,

[https://dns.google.com/resolve?name=example.com](https://dns.google.com/resolve?name=example.com).

[http://stat.ripe.net/data/dns-
chain/data.json?resource=examp...](http://stat.ripe.net/data/dns-
chain/data.json?resource=example.com)

[http://dns-lg.sidnlabs.nl/example.com/A?tcp=1](http://dns-
lg.sidnlabs.nl/example.com/A?tcp=1)

------
markhahn
dns over quic would be more interesting.

------
knodi
Firefox 60 (nightly) has support for this.

~~~
aorth
You're thinking of DNS over HTTPS, which Firefox nightly does have support
for. This submission is about DNS over TLS, which has been around a little
longer and has a few working DNS clients and servers already. :)

------
teknopaul
I really dont see the point in trying to make dns secret. You need a lock on
the front door but you also need a door bell.

~~~
LethargicStud
Because privacy is good. There could be countries that could physically harm
you for accessing certain sites. This is a good step to avoiding that.

~~~
amelius
But said countries could still see what IP addresses you talk to, and do a
reverse DNS lookup ...

~~~
BuildTheRobots
Reverse IP doesn't necessarily tell you much - especially with the
predominance of "shared hosting" (or even cloudflare type services). The IP
address could potentially be one of 1000 sites, so your ISP shouldn't be able
to tell what you're actually looking at (eg they have no idea if you're
looking at porn, nazis or just reading the local news paper).

Sadly SNI destroys most of this privacy, but leaking less shouldn't be a bad
thing. There's also other reasons you don't want people intercepting or re-
writing your DNS.

~~~
amelius
> Reverse IP doesn't necessarily tell you much

Yeah, but put some strong emphasis on "necessarily" there.

I don't buy this argument. There are too many situations in which it doesn't
apply. It offers a false sense of security.

~~~
verandaguy_alt
Lots of edge cases with an extremely large base case -- I'd guess
(conservatively) that at least 9 out of 10 sites you go to use shared hosting
or a CloudFlare-style CDN.

Also worth noting that an ISP will generally go for the low-hanging fruit, but
if your threat model includes a determined opponent then this probably isn't
for you.

It's hard to argue that this isn't a net improvement over the status quo,
though.

