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.
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.
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.
> 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].
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 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'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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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. :(
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.
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.
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. :)
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.
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.
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