DNS over HTTPS vs. TLS—Key Concepts, Implementation Guidelines, and Recommendations.

When you access a website, the padlock icon in your browser tells you whether the website you visit is secure. This is because your browser and the web server have agreed on an encryption mechanism before any data exchange is done between the two. This ensures that your communication with your bank or social media site remains secure over the Internet. 

However, one traditionally overlooked prior step of communication is DNS resolution. The Domain Name System (DNS) functions like the Internet’s phone book, translating readable website names into numerical IP addresses. When you type a web address into your browser, it sends a DNS query through a chain of configured DNS servers to determine the associated destination IP address. 

Communication with DNS servers is still mostly done in clear text, and malicious entities can eavesdrop on this information. In the following article, we discuss the new standards being implemented to address the privacy concerns related to the Domain Name System.

Summary of key DNS over HTTPS vs TLS concepts

	DNS over TLS	DNS over HTTPS
How it works	The client directly encapsulates the DNS data into TLS.	The DNS communication is first prepared as an HTTP request and then transported using TLS.
Preferred use case	Where network visibility is required	Where privacy is a significant concern.
Performance	Comparatively faster than DoH	Comparatively slower than DoT. The difference in delay is minimal but is still there due to the additional protocol overhead of HTTPS.
Privacy	A lower level of privacy as DNS network traffic is visible.	Higher level of privacy as DNS is transported within HTTPS.
Censorship bypass	Potentially lower possibility of censorship bypass.	Higher level of censorship bypass.
Network Port	853	443

Traditional DNS and its vulnerabilities

The DNS communications today are being done mostly on clear text channels. When your computer makes a DNS query, it shares two critical pieces of information, which raises privacy concerns—the QNAME, or the site you are trying to get to, and your source IP Address. 

The QNAME is the starting point for DNS queries, representing the domain name or service being sought. Depending on the type of service or information requested, the DNS query seeks out different record types. For example,

• A record—direct IP address resolution
• MX record—email delivery
• SRV records—VoIP or directory services

Someone with network path access between your computer and the DNS resolver can tap into the network, capture your information, and gather your intent. For example, the attacker can determine if you are accessing a specific website, emailing, or requesting a specific service type.

To address such privacy issues, the Internet Engineering Task Force (IETF) has proposed improvements to the DNS standards by increasing encrypted transport mechanisms. The most notable standards proposed by the IETF for this purpose are DNS over HTTPS and DNS over TLS.

DNS over TLS

DNS over TLS (DoT) secures DNS queries by wrapping them in Transport Layer Security (TLS) encryption, a successor to Secure Socket Layer (SSL). The IETF specifies DNS over TLS in RFC 7858. 

TLS and how it works

TLS uses both symmetric and asymmetric encryption mechanisms to secure data transfers. The process, explained below, is also called a TLS handshake.

1. The client initiates a client Hello message to the server, which includes the highest TLS version the client supports.
2. The server responds with a server hello message and the chosen TLS version.
3. The client and the server agree on a shared secret that will be used to encrypt and decrypt data during the session.
4. The server sends its digital certificate to the client, including the server’s public key, which a Certificate Authority (CA) trusts.
5. The Client and the Server derive session keys from the shared secret.

These keys encrypt and decrypt data between the client and the server. The session key is discarded once the communication session is over.

How DNS over TLS works

Port 853 is the standard port designated for DoT services. DoT-capable DNS servers are configured to listen and accept connections from clients for incoming DNS queries on this port. A dedicated port helps distinguish DoT traffic from other network traffic types, allowing for easier management of encrypted DNS queries. For scenarios where network configurations require traffic routed through specific ports (like firewall traversal, policy enforcement, or other reasons), the client and server can mutually agree to use another port. Changing the default port requires reconfiguring both.

When the DNS client needs to resolve a domain name, it establishes a Transmission Control Protocol (TCP) session with the DoT-capable DNS server on port 853. The process involves the TLS handshake, during which the client and server exchange cryptographic information. The client then passes on encrypted DNS queries to the server, which returns encrypted responses.

To increase the performance, the client can pipeline multiple queries to the DNS server in the same TLS session. This avoids the overhead of repeatedly establishing a TCP connection and then a TLS session.

The DoT traffic is encrypted over the wire, and its contents cannot be read, but this does not necessarily prevent all forms of DNS tracking by ISPs. It is still identifiable as DNS traffic as the client and server typically communicate over the specific port 853.

DNS over HTTPS

DNS over HTTPS (DoH) is a protocol that performs DNS resolution via the HTTPS protocol. This means that DNS queries are sent to the resolver using HTTPS as the transport layer, ensuring they are encrypted along with the rest of HTTPS traffic. The IETF specifies DNS over HTTPS (DoH) in RFC 8484. 

How HTTPS works

The Hypertext Transfer Protocol (HTTP) is the primary communication protocol of the Internet. The protocol does not provide security by itself as its header and payload are human-readable. Its secure version (HTTPS) relies on TLS to secure data exchange over the public Internet. 

When a client browser requests any webpage from a server, the client computer first establishes a TCP connection with the server and then a TLS session between the client and the server (as explained above). After the TLS handshake, the client browser uses the TLS session to encrypt the HTTP requests to the web server. The web server uses the same TLS session to respond with the required data.

How DNS over HTTPS work

DoH works like a standard HTTPS protocol over the same port 443, making DoH indistinguishable from regular HTTPS traffic over a network.

At the core of DoH operation is the specification of a URI (Uniform Resource Identifier) that points to the DoH server. This URI, such as https://dns.server.net/dns-query, is essentially the web address of the DoH service, and it specifies where the DNS queries should be directed within the server’s namespace.

End users can often configure the DoH URI within their browsers or DNS clients. Modern browsers like Firefox, Chrome, and Edge offer settings where users can enter the URI of their preferred DoH server based on criteria like privacy policies, performance, or jurisdiction. In organizational networks, network administrators configure DoH URIs to enforce specific DNS resolution policies. ISPs or DNS service providers can also automate the configuration of DoH URIs using the Dynamic Host Configuration Protocol (DHCP). 

Using the defined URI, the client can use the HTTP GET or POST method to resolve the required DNS query from the DoH server. The HTTP body represents the DNS request as a media type application/dns-message. The client and server exchange DNS requests and responses over a secure TLS connection.

Implementing DNS over HTTPS and DNS over TLS

Before selecting a public DoT or DoH resolver, one should understand the chosen service provider’s privacy and security policy. Although the DNS traffic would be encrypted between the end client and the DNS server, the DNS server would still be able to identify the client IP and record the queries being resolved by the client.

DNS providers supporting DoH and DoT

Following is a list of some well-known open resolvers that support DoT and DoH

Provider	IP Address	TLS Port	DOH URL
Cloudflare	1.1.1.12606:4700:4700::1111	853	https://cloudflare-dns.com/dns-query
Quad9	9.9.9.92620:fe::fe	853	https://dns.quad9.net/dns-query
Google	8.8.8.82001:4860:4860::8888	853	https://dns.google/dns-query

Operating systems  supporting DoH and DoT

The DoT and DoH are relatively newer standards and require manual configurations at the client end in most cases to enable these protocols. 

Operating System	DoT	DoH	Notes
Apple macOS 11 (Big Sur and later)	Yes	Yes	Native support for both DoT and DoH in Network Preferences.
Apple iOS (14 and later)	Yes	Yes	Native support for both DoT and DoH is available through DNS profiles or apps.
Google Android (9 and later)	Yes (Limited)	Yes	Native support for DoT with limited DoH options in developer settings (Android 11 and later).
Windows 11 and Windows Server 2022	Limited	Yes	Native support for DoH only. Limited DoT support might be available through third-party tools.
Linux Distributions (varies)	Yes	Yes	Support varies depending on distribution and configuration. Typically requires manual setup using tools like systemd-resolved.

Browser support for DoH

Browser	Version	Comment
Firefox	Ver 62 onwards (since 2019)	https://support.mozilla.org/en-US/kb/firefox-dns-over-https
Chrome	Ver 83 onwards (since 2020)	https://blog.chromium.org/2020/05/a-safer-and-more-private-browsing-DoH.html
Bromite	Ver 67.0.3396.88	https://github.com/bromite/bromite/wiki/DNS-over-HTTPS

Implement your own DoT and DoH server with PowerDNS DNSDIST

You can implement DoT and DoH for your organization using the PowerDNS DNSDIST application without changing existing DNS resolvers. DNSDIST is an open-source DNS load-balancer that can be deployed in front of any DNS resolver and can provide standard DNS, DoT, and DoH capability. PowerDNS provides a software repository for most common Linux distributions. The instructions for installing DNSDIST via repositories are available at the PowerDNS repo site.

After installation, the application needs to be configured. We can define multiple backend servers to load-balance DNS traffic and provide failover capability. Edit the file /etc/dnsdist/dnsdist.conf with the following configuration.

-- define downstream servers, aka backends
-- https://dnsdist.org/guides/downstreams.html
newServer("1.1.1.1")
newServer("2606:4700:4700::1111")
newServer("8.8.8.8")
newServer("2001:4860:4860::8888")

Next, we need to enable the listening service of DNSDIST to accept connections on standard DNS port 53. To enable DoT and DoH you need to provide a proper CA signed certificate and key. Add the following configurations to the DNSDIST configuration file.

-- accept plain DNS (Do53) queries on UDP/53 and TCP/53
addLocal("0.0.0.0:53")

-- accept DNS over TLS (DoT) queries on TCP/853
addTLSLocal('0.0.0.0:853', {"/etc/ssl/domain-cert.pem"}, {"/etc/ssl/domain-cert.key"})

-- accept DNS over HTTPS (DoH) queries on TCP/443
addDOHLocal("0.0.0.0:443", {"/etc/ssl/domain-cert.pem"}, {"/etc/ssl/domain-cert.key"}, "/dns-query")

After configuration, the DNSDIST service needs to be (re)started, and you will now have your own DoT and DoH resolver.

DNS over HTTPS vs. TLS 

Both DoT and DoH have been designed to protect DNS traffic between client and DNS server from prying eyes over the public Internet. For this purpose, both rely on the security and encryption mechanisms of TLS. Also, both protocols run over the TCP transmission layer. However, the primary difference between the two is that:

• In DoT the client directly encapsulates the DNS data into TLS
• In DoH, the DNS communication is first prepared as an HTTP request and then transported using TLS. 

Implementing DoT and DoH increases the latency in the DNS resolution process compared to unencrypted UDP DNS queries. In DoH, the additional step of encapsulating the DNS communication in HTTP and transporting it over TLS/TCP causes a slightly bigger delay than DoT.  

Use cases

DoT is preferred in organizations where network visibility and control are required. DoT uses a dedicated port (853), which allows network administrators to monitor DNS network traffic. However, the DNS content is still invisible unless the organization implements its own DoT or DoH resolver.

DoH is preferred where the focus is on privacy. DoH utilizes the same port (443) as HTTPS traffic, effectively camouflaging DNS queries within web browsing activity. DoH can also facilitate users’ bypassing restrictions in regions that implement DNS-based censorship, as it can bypass restrictions on specific DNS resolvers.

It is also important to note that DoT and DoH have been designed primarily for the privacy of end users. This may cause challenges for organizations implementing DNS-based filtering for parental control or malware protection. Encryption makes the user’s DNS traffic invisible, and the organization loses the visibility and control it previously had. 

Improving DNS over HTTPS and DNS over TLS 

The following improvements are needed for both DoH and DoT

Latency

To improve the latency of DNS resolution and provide the same security and privacy features, a new protocol standard DNS over QUIC has been proposed in RFC 9250. The QUIC protocol uses the encryption capability of TLS 1.3 but utilizes UDP instead of TCP for more efficient transport layer communication. Additional multiplexing optimizations and improvements in TLS 1.3 further reduce the latency.

Multi-level security

The DoT and DoH protocols provide encryption and privacy for communication between the DNS client and DNS resolver. However, the communication between the DNS resolver and authoritative servers still works over standard unencrypted DNS protocol.  An experimental RFC 9539 has been proposed, but there is no standard implementation yet. 

The two protocols also cannot protect against other types of DNS threats like DNS spoofing or cache poisoning. For protection against such attacks, the DNS Security Extension (DNSSEC) has been standardized to provide data origin authentication and data integrity protection. DNSSEC adds digital signatures to the DNS responses which the clients can use to authenticate that data comes from an authentic zone and has not been modified in transit. DNSSEC however, does not encrypt the responses which remain in clear text while in transport and thus cannot act as an alternate to DoT/DoH.

Tracing

How quickly your DNS resolves for a user is their introduction to your brand. Tracing DNS issues back to the correct resolution level is usually a headache. LogicMonitor helps you quickly determine whether your DNS is at fault and at what level in the resolution chain the problem occurred. Regardless of the resolution level, you can pinpoint issues anywhere in your DNS hierarchy. You also gain instant access to DNS response times and network-level metrics – all without installing any agents.

Final thoughts

In the article, we have highlighted the privacy concerns related to the standard DNS resolution process and how the newer DoT and DoH protocols have been designed to address the challenges. Both protocols share an encryption layer but differ in the network visibility and level of privacy each provides. 

They are relatively newer protocols than the original DNS standard, but their implementation is still not ubiquitous. Also, the DoT and DoH have some potential performance impact, which is being addressed in the even newer proposed protocol, DoQ.