RFC 7858: DNS over TLS (2016) | Hacker News Reader

RFC 7858: DNS over TLS (2016)

tools.ietf.org

156 pointswalrus0153 comments

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

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.

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...

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.

> To maintain the performance of DNS, you'd want a connectionless protocol.

What you're looking for is DNSCurve.

The only reason people are interested in DNS over TLS is the garbage middleboxes that intercept and interfere with DNS (and thereby break DNSCurve or anything like it), which typically don't interfere with TLS.

If you could use an arbitrary protocol then it might as well be DNSCurve. If you can't then it has to be TLS. Even DNS over DTLS is people not realizing why TLS was used to begin with.

It seems the thing to do is to default to DNSCurve and fallback to DNS over TLS/HTTPS if that fails.

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.

Well unless your upstream DNS provider suddenly moves to support this protocol, what do you expect to happen?

Set it manually.

> OK so which is more likely to play nice with constantly changing wireless connections?

If you use a public resolver that supports it (such as Cloudflare's 1.1.1.1), I think you'd probably be best served by DNS-over-HTTPS as it uses 443/TCP.

DNS-over-TLS (supported by 1.1.1.1 and 9.9.9.9) would be my next choice, but since it uses 853/TCP, you might run into issues if/when you encounter a wireless network that blocks outbound access to this port.

DNSSEC, if you ran your own validating resolver on your laptop, should work regardless of the network you are connected to (as it just uses 53/UDP), but with the caveat that DNSSEC does not provide privacy (just "response integrity", as noted by the RFC).

> ... out of the box, Windows and macOS and Fedora all just defer to the DNS servers that are assigned by DHCP ... So I'm pretty much stuck, ...

Even when using DHCP, you should still be able to manually configure the DNS servers you want to use. AFAIK, this is still possible on any OS (but I haven't used Windows for years, nor OS X for quite a while). For example, on my laptop (which also hops between wireless networks), I run my own resolver (unbound, which points to a recursive resolver on the Internet that I control) and use DNS-over-TLS (on 853/TCP).

For more information, see the DNS Privacy Project's web site (wiki) [0].

[0]: https://dnsprivacy.org/wiki/

If you run and fully control your own recursive resolver, it's also possible (but non standard) to run DNS-over-TLS on port 443. The general steps are to install stunnel for a TLS proxy on the DNS server, set it up with the appropriate public/private keys, and then have stunnel forward traffic to localhost:53 on the same machine.

DNS over QUIC has a concept of an IP address independent session id, which maintains the crypto state and session state across multiple IP bindings. i suspect you're heading to a space where DNS on QUIC is better for you than DNS on TLS.

its still in draft state AFAIK

DNS over HTTPS (DoH) is available now in Firefox Nightly; the beauty is Firefox can use (for example) Cloudflare’s DoH servers regardless of what the system’s DNS settings are—even on macOS: https://facebookexperimental.github.io/doh-proxy/tutorials/f...

> I'm pretty much stuck, out of the box, with AP specific DNS policy.

It certainly isn't "out of the box", but on the off chance it's useful to you -- you can change dhclient (/etc/dhcp/dhclient.conf) to specify your own DNS servers. This is what I do, pointing at a bind instance I run, and it provides plenty of warm feels. Or, heck, you could run a full resolver locally.

A full resolver locally would just send out the same plain DNS queries -- it doesn't have any local database to resolve from.

At first, but it caches zones when resolving (up to the TTL) so over time the traffic decreases.

But your browser already does that.

DNS over TLS uses a new port. If you're on an enterprise network, its firewall probably blocks that port.

DNS over HTTPS is being discussed to resolve that problem. The downside is it doesn't really exist yet.

DNSSEC doesn't do anything for query privacy (in other words: most of the reasons you'd use DNS-over-TLS aren't addressed by DNSSEC). DNSSEC is a bad standard whose primary impact on the Internet would be to replace the LetsEncrypt CA system with a PKI run by world governments. That sounds like something InfoWars would say, but I promise you, DNSSEC is weirder than InfoWars.

For now, the right answer is DNS over TLS.

What is the point of "query privacy" when browsers send host addresses in plaintext (SNI) and destination IPs are still visible to the internet provider?

Layering DNS over TLS (or anything else) is meaningless, it increases RTT (and thus response time) without any benefit for most users.

It's mostly for preventing DNS response integrity I'd say.

Using DNS over HTTPS or over TLS to hide traffic from your ISP is utterly meaningless. I don't know why people are advocating it for 'privacy' from your ISP.

For privacy, one would just use a VPN for all their traffic and using DNS over HTTPS matters much less, given that the DNS resolver is also being routed over the VPN connection (if it does at all).

The only use I see is that if you're visiting a HTTPS website, and it doesn't have HSTS (or if you're visiting a website with HSTS for the first time), it prevents phishing (for less tech-savvy since one would notice that it won't be TLS) people.

This use is further diminished if Firefox and other browsers start implementing the HSTS preloading[1] feature like Chrome, and people actually start submitting their domains for inclusion. Which I don't see happening soon, so it has some use case.

[1]:https://hstspreload.org

DNSSEC is for authoritative signing of domains, not TLS1.2 level security for an individual client (stub resolver) requesting a record from a recursive resolver.

DNS-over-TLS and DNS-over-HTTPS accomplish the latter.

jlgaddis' answer addresses it quite well. One note to add, if you're on a wifi network where you know that the DHCP server assigns IPs in a certain range (such as from 10.100.100.80 to 10.100.100.250) and you have the correct WPA2-AES key, you can totally associate to the wifi, disable DHCP and manually assign yourself the static IP of 10.100.100.70 or whatever, the correct default gateway, and manually chosen DNS servers.

None of the above. Captive authentication portals are common in most "constantly changing" wireless client scenarios. Many use a DNS MITM approach that requires you to have working DNS service to the resolver you were provided by DHCP, and few today permit HTTPS service to DNS servers at any address, especially 1.1.1.1. Enforcing DNS-over-TLS, -HTTPS, or DNSSEC on your wireless client will not be a viable configuration in these real-world instances.

captive portals are an ugly hack that should be reimplemented properly (without MITM) based on the obvious need.

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.

I'm using dnscrypt-proxy on my router as well (Netgear with OSS firmware). working great so far.

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.

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...

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

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. :)

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.

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.

For authoritative responses, DNSSEC exists.

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

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.

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. :(

If you run your own recursive resolver that kind of defeats the point doesn't it?

I found this guide (with slight modifications) helpful for setting up stubby as a localhost DNS resolver to proxy through 1.1.1.1 with DNS-over-TLS on macOS: https://medium.com/nlnetlabs/privacy-using-dns-over-tls-with...

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.

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?

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

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

Not actually sure but I believe CoreDNS can be used as a resolver and supports a wide array of modern DNS standards.

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.

http://stat.ripe.net/data/dns-chain/data.json?resource=examp...

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

DPRIVE maintains a list with current implementation status https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implement... (you're looking for TLS encryption + OOOR + pipelining)

BIND 9.11 (needs a TLS proxy) and dnsdist (needs a back-end resolver), maybe Knot and PowerDNS but I haven't tested them

dns over quic would be more interesting.

Firefox 60 (nightly) has support for this.

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. :)

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.

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.

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

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.

> 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.

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.

What a silly thing to say.

Reply on news.ycombinator.com