What is DNS over TLS? Everything you need to know
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

What is DNS over TLS? Everything you need to know

Prevent ISPs from seeing what website you’re viewing with DNS over TLS

DNS over TLS keeps Internet Service Providers (ISPs) from spying on users. Doesn’t SSL already do that? Sort of. An SSL certificate facilitates an encrypted connection between a client’s browser and a website’s server. That means that during the connection all communication and activity are obscured.

But, the ISP can still see what website you’re on.

It doesn’t have to be that way though, there is a way to keep your ISP from even seeing what website you’re accessing. It’s called DNS over TLS.

What is DNS over TLS?

DNS over TLS is a security protocol that forces all connections with DNS servers to be made securely using TLS. This effectively keeps ISPs from seeing what website you’re accessing.

There’s a lot to unravel here, so let’s start from the beginning.

TLS or Transport Layer Security is the successor to SSL. Despite still being the colloquial term for TLS, SSL was actually not a secure protocol and was quickly replaced by TLS. What you call an SSL certificate is actually a TLS certificate. So just remember, when we say TLS we’re talking about the concept of SSL.

Now, let’s talk about DNS.

What is a DNS server?

DNS stands for Domain Name System, which actually means calling it a DNS Server is redundant—but indulge me. DNS Servers are what translates the web address you enter into the IP address your computer recognizes when it serves the website.

When you type in a web address, you’re typing in a URL or a Uniform Resource Locator. Behind the scenes, your browser is making a connection with a DNS server that translates that URL into an IP address, which it uses to server the files on the server. Again, this all happens quickly behind the scenes. The average internet user has no idea it’s even taking place.

Unfortunately, most DNS requests are made in plaintext, which means your ISP can see the conversions. That means they can see what website you’re accessing even if that website has SSL to obfuscate what pages you’re viewing.

Currently the requests are made via the UDP or TCP protocols.

Enter DNS over TLS

DNS over TLS is actually specified in RFC 7858. It requires all DNS data be sent on a DNS-over-TLS port. When using TCP Fast Open, the TLS handshake must be initiated immediately.

The TLS handshake is process where a TLS connection is negotiated.

Adoption depends entirely on the DNS industry. If a server is equipped with SSL/TLS, DNS over TLS is within its capabilities—it’s just a matter of supporting it.

Recently, Android announced it would be adding DNS over TLS for all of its apps. This makes sense, considering Google’s DNS servers already support DNS over TLS. If you want to enable DNS over TLS, it’s just a matter of finding a DNS server that supports it.

We highly recommend DNS over TLS, just like we recommend enabling HSTS on your website. It’s important to close as many attack vectors as possible. SSL/TLS is a great tool, but it’s not a cure-all. It’s important to have to correct implementations to maximize

What we Hashed Out (for Skimmers)

Here’s what we covered in today’s discussion:

  • DNS over TLS is a protocol that forces all DNS requests to be made securely
  • This practice prevents ISPs from seeing what websites you’re trying to access
  • To use DNS over TLS your DNS service must support it.
    • No DNSSEC verifies that the DNS Server you requested is actually the one responding to your request, it signs, rather than encrypts requests.

    • Very. DNS over TLS encrypts the communication from the client to the DNS server. The data however may or may not be invalid. E.g. you ISP’s, or Google’s, or Cloudflare’s DNS servers may return whatever they want.

      DNSSEC is a way to have the zone data signed so that the results are not tainted. A non-master DNS server cannot chose to return bogus results because it doesn’t have the private key to sign the zone again.

  • Maybe I’m missing something. The article says, “Prevent ISPs from seeing what website you’re viewing with DNS over TLS.” That is not true at all. If your ISP is sniffing your packets, they can see what sites your hitting, even if your DNS is TLS-encrypted. In the HTTPS header, thanks to the SNI (Server Name Indication) extension to TLS, your web browser states in plaintext what site you want to open during the TLS negotiation. It doesn’t show the URL (but neither does a DNS request).

    The only way to really hide stuff from your provider is via VPN or some other encrypted tunneling method (like SSH). If you’re doing that, your DNS requests are also encrypted anyway, even without DNS over TLS.

    • You’re missing something. The ISP will only see the request to the DNS server. The SNI will only show the IP of the DNS server. The site you are requesting is encrypted, no one in between the client and the DNS server will know what site was requested.

      • So after the web server IP is resolved ‘in secrecy’ through DNS-over-TLS, isn’t our browser still making a hit to the webserver’s IP address? Wouldn’t our dear MitM still knows which IP we are visiting?

      • If you check the Client Hello packet in a TLS negotiation, there is an extension called server_name. The server name being requested is right there in the header, in plaintext. Do a packet capture if you don’t believe me. This is an easy place to read about it: https://idea.popcount.org/2012-06-16-dissecting-ssl-handshake/ ; scroll down to the “extensions” section.

        A little non-technical advice to help you as you go through life: before you “correct” someone, ensure that your correction is valid.


        • Matt you are referring to every day TLS negotiations between clients and servers, aka (myself) connects to startpage.com; DNS over TLS is another thing. Have you taken the time to look at DNS over TLS packets? I am now browsing without DNS-TLS, and checking TLS-1.2 “client hello” packets while wireshark in Linux Mint. I see no extension labelled “server_name”. However, looking through the raw packet data I do see the name of the server embedded within the “hello” packet. “www.startpage.com” etc. Perhaps this is what you are referring to. However this is not “DNS” traffic. DNS over TLS will only expose the DNS server you’re connecting to, instead of every dns query. Combined with DNSSEC TLS over DNS will ensure no MITM. And the majority of your data will be encrypted. DNS is easy pray. As far as I can tell, snoopers will have to examine raw packets to gain TLS data, that is costly and likely require more targeted measures. One thing is for sure, DNS is is far more secure with TLS; and DNSSEC essential, to ensure the DNS server itself is not being spoofed with a MITM; So your ISP can still know you are connecting to “this website” or “that website” if they really want to dig through it all, if you are not using a VPN. If you’re on a VPN you’re good to go.

          • TAYLOR2: TLS SNI is a well known extension. Clients will provide a “destined” server name they intend to speak with. On the server, this extension can be read to allow the server to choose which TLS certificate/key to use for the TLS handshake, dynamically, while still only binding to a single ip/port. Before this extension, it was impossible for a server to intelligently serve up different TLS certificates for a TLS handshake on a single port binding; so the single certificate that was being served must have a CN and/or SANs that match the client/user-agent’s expectations. With the SNI extension, servers can have different certificates for different backends, while serving clients from a common port binding. This is most useful for front-end proxy servers.

            The SNI extension in the ClientHello record is called “server_name” and typically will have the full hostname (e.g. http://www.google.com) in plaintext with which the client intends to connect. Thus, this offers the same problems as regular DNS to snooping eyes in terms of privacy.

          • The comment engine turned my server_name example into a hyperlink, and added https:// to the front of it. Hopefully that did not distract from the point that TLS SNI—which is widely supported on modern user agents and TLS infrastructure and becoming only more pervasive—has the same issue as DNS in terms of privacy (specifically, knowing what websites someone is browsing). Obviously IP packets are never able to be private, so if a public IP is very well know and fairly static, that will always be available to snooping eyes.

  • Ive been using DNSoTLS on a RaspberryPi running Stubby and processing through dnsmasq for 3 months now. I asked my ISP to provide me with my 2018 log files, which clearly indicate no plain text hostnames. They no longer know what sites I’ve visited.

  • You’re not “good to go” with vpn
    A lot of vpn companies are liars who keep way more records than your actual ISP would and sell your logs to everyone including your isp and you end up finding some isp companies being more private than 90% of the vpn companies
    Such as linus tech tips was suggesting bear vpn but bear vpn was keeping logs and selling logs to everyone

    Only vpn that doesn’t do that kind of dodgy proffit by not keeping and records by surviving on subscribers alone is good to go

  • And the very thing a lot of isp companies try to protect you from to keep your privacy intact

    Are vpn companies trying to get privacy removed from us to sell your data by bribing governments with your vpn money to pressure ISP to give them more data to sell

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *


Patrick Nohe

Patrick started his career as a beat reporter and columnist for the Miami Herald before moving into the cybersecurity industry a few years ago. Patrick covers encryption, hashing, browser UI/UX and general cyber security in a way that’s relatable for everyone.