DNS over HTTPS (DoH) is a protocol that encrypts DNS queries and responses by sending them over HTTPS, the same encrypted protocol used to secure web traffic. Defined in RFC 8484, DoH protects DNS traffic from being read or modified by parties observing the network path between the client and the DoH resolver.
DoH improves the privacy and integrity of DNS traffic, but it does not make DNS activity completely private. The DoH resolver still receives and processes the queries, while the network can still observe the connection to the DoH service.
For enterprises, DoH introduces another challenge. When browsers or operating systems use DoH to send DNS queries directly to public resolvers outside the organization's DNS infrastructure, administrators may lose visibility into DNS activity and the ability to apply existing DNS-based policies. Managing DoH in enterprise environments therefore requires balancing the privacy benefits of encrypted DNS with the organization's requirements for DNS visibility, security, and policy enforcement.
The privacy problem with traditional DNS
Traditional DNS mostly uses UDP port 53 without encryption. A DNS query includes the domain name being resolved, and when the query is sent in plaintext, parties that can observe the network path between the client and resolver can read it.
This creates a privacy exposure that exists independently of HTTPS. Even when a user accesses a website over HTTPS, where the content exchanged with the website is encrypted, the DNS query made before the connection can reveal the domain being accessed. An ISP monitoring plaintext DNS traffic can see the domains a user resolves. Similarly, a Wi-Fi operator can observe DNS queries from devices on its network, while an attacker with access to network traffic can use those queries to infer a user's browsing activity without decrypting the website content.
Plaintext DNS also provides limited protection against tampering on the network path. An attacker positioned between a client and its resolver may be able to modify a DNS response and return a false IP address, potentially redirecting the client to a malicious server. This type of DNS spoofing or manipulation is possible because traditional DNS does not encrypt or protect the exchange between the client and resolver.
DoH addresses these weaknesses by sending DNS queries and responses through an encrypted HTTPS connection. This protects the DNS exchange from parties observing the network path and helps prevent them from modifying the traffic in transit. However, the DoH resolver itself can still see and process the DNS queries.
For a detailed explanation of how DNS resolution works before DoH is introduced, see our guide on how DNS works.
How DNS over HTTPS works
DoH carries DNS queries and responses through standard HTTPS requests. Instead of sending a DNS query directly to a resolver over traditional DNS transport, the client sends an HTTP GET or POST request to a DoH server's HTTPS endpoint, typically over port 443.
The DNS message uses the standard DNS wire format and the application/dns-message media type. For a POST request, the DNS message is carried in the request body. For a GET request, the DNS message is encoded as a URL parameter. The DoH server receives the request, extracts the DNS message, and processes it using a DNS resolver. It then returns the DNS response in the same DNS wire format within an HTTPS response.
The important difference is the transport between the client and the DoH server. TLS encrypts the HTTPS connection, so a device observing the network path cannot directly read the DNS query or response. The observer can still see that the client is communicating with a particular server and may be able to infer traffic patterns, but the DNS contents are protected by TLS.
DoH server endpoints
DoH providers expose DNS resolution through HTTPS endpoints. For example:
- Google Public DNS: https://dns.google/dns-query
- Cloudflare: https://cloudflare-dns.com/dns-query
- Quad9: https://dns.quad9.net/dns-query
- NextDNS: https://dns.nextdns.io/
Organizations can also deploy DoH-capable DNS resolvers for internal use. This allows DNS queries to be encrypted between clients and the organization's resolver rather than sending them to a public DoH provider.
Protocol and transport
DoH is defined by RFC 8484, published in 2018. It uses HTTP as the application-layer transport and can operate over HTTP/2 and HTTP/3.
HTTP/2 and HTTP/3 support multiplexing, allowing multiple DNS queries to share an existing connection rather than establishing a separate connection for each query. This reduces connection overhead and makes DoH more efficient for clients generating a large number of DNS queries.
DoH vs. DNS over TLS (DoT)
DNS over HTTPS (DoH) and DNS over TLS (DoT, defined in RFC 7858) both encrypt DNS queries and responses, but they differ in how DNS traffic is transported and how easily networks can identify and control it.
| DNS over HTTPS (DoH) | DNS over TLS (DoT) | |
|---|---|---|
| RFC | RFC 8484 (2018) | RFC 7858 (2016) |
| Transport | HTTPS over TLS, using HTTP/2 or HTTP/3 | TLS directly over TCP |
| Default port | 443 | 853 |
| Network visibility | DNS content is encrypted and carried within HTTPS traffic; the DoH destination may still be identifiable | DNS content is encrypted, but traffic to port 853 clearly identifies the connection as DoT |
| Port-based control | More difficult because port 443 is also used for regular HTTPS traffic | Easier because port 853 is dedicated to DoT |
| Enterprise control | Requires endpoint policies, resolver controls, firewall rules, or other mechanisms to manage approved DoH services | Can be controlled more directly through firewall and network policies targeting port 853 |
| Typical use | Privacy-focused DNS on browsers, operating systems, and other clients | Encrypted DNS where explicit network-level identification and control are useful |
| Key consideration | Blends DNS transport with ordinary HTTPS traffic | Provides a clearly identifiable encrypted DNS channel |
The primary difference is therefore how the encrypted DNS traffic is transported, not whether one protocol encrypts DNS better than the other. Both protect DNS queries and responses from being read by parties observing the network path.
For enterprises, the distinction matters because DoT uses a dedicated port that network security controls can identify and filter independently. DoH uses HTTPS, typically over port 443, so simple port-based filtering cannot distinguish DoH from other HTTPS traffic. Organizations that need to control DoH therefore typically rely on additional controls, such as endpoint policies, approved resolver configurations, firewall rules, DNS security policies, or blocking known unauthorized DoH endpoints.
DoH vs. traditional DNS: Key differences
Traditional DNS and DNS over HTTPS perform the same fundamental function by resolving domain names to DNS records but differ in how DNS traffic is transported and protected.
| Traditional DNS | DNS over HTTPS (DoH) | |
|---|---|---|
| Transport | UDP (typically) or TCP | HTTPS over TLS, using HTTP/2 or HTTP/3 |
| Port | 53 | 443 (typically) |
| Encryption | None by default; DNS messages are sent in plaintext | TLS encrypts the DNS exchange between the client and DoH server |
| Query visibility | Domain names can be read by parties observing the network path | DNS contents are hidden from network observers, but remain visible to the DoH resolver |
| Tamper resistance | No encryption or transport-level integrity protection | TLS helps prevent modification of DNS traffic in transit |
| Connection overhead | UDP has low connection overhead; TCP requires a connection | Initial TLS and HTTPS connection setup can add overhead, while persistent HTTP/2 or HTTP/3 connections can reduce it |
| Enterprise DNS policy | Policies can be enforced through the organization's DNS infrastructure | Existing DNS controls can be bypassed when clients use unauthorized external DoH resolvers |
| Network control | Easy to identify and filter using DNS traffic and port 53 | More difficult to distinguish from other HTTPS traffic using port-based controls alone |
The difference here is where DNS is protected and how the traffic can be controlled. Traditional DNS exposes queries on the network path, while DoH encrypts the exchange between the client and the DoH resolver. However, DoH does not eliminate the need for DNS security or management controls; organizations still need to decide which resolvers clients can use and how DNS policies are enforced.
Benefits of DoH
DoH offers several benefits, particularly for DNS privacy, security, and accessibility across different network environments. Here are some of its key advantages:
Protects DNS queries from network observers
DoH encrypts DNS queries and responses between the client and the DoH resolver, preventing parties observing the network path from directly reading the domain names being queried. This closes a privacy gap that remains even when websites themselves use HTTPS: HTTPS protects web traffic, while DoH protects the DNS exchange that precedes the connection.
Protects DNS traffic from in-transit tampering
TLS provides both confidentiality and integrity for the DoH connection. An attacker observing the network path cannot modify a DNS query or response without causing the protected connection to fail validation. This helps prevent network-level DNS spoofing, where an attacker manipulates an unencrypted DNS response to redirect a client to a malicious IP address. DoH protects the connection between the client and the DoH resolver, but it does not validate the correctness of the resolver's response. If a resolver is compromised or configured incorrectly, DoH alone cannot detect an incorrect DNS answer.
Works across networks that restrict traditional DNS
DoH typically uses HTTPS over port 443, allowing DNS resolution to operate on networks where traditional DNS traffic on port 53 is restricted or filtered. This can be useful for devices connecting from public Wi-Fi, mobile networks, and other environments where direct DNS access is limited.
Makes DNS transport harder to distinguish from ordinary HTTPS
Because DoH uses HTTPS, DNS traffic shares the same general transport as regular web traffic. Network controls that rely only on DNS-specific ports cannot distinguish DoH from other HTTPS traffic. This can improve DNS availability in networks with restrictive or tightly controlled DNS access, although it also makes unauthorized DoH more difficult for enterprises to identify and manage.
DoH in enterprise networks
DoH improves DNS privacy for end users, but it can create operational challenges when clients use external DoH resolvers instead of the organization's DNS infrastructure. Enterprise DNS environments often depend on centralized resolvers for internal name resolution, security policies, logging, monitoring, and other network controls. Sending queries directly to an external DoH service can move those functions outside the organization's control.
Internal name resolution can fail
Private DNS names, such as app01.corp.local or intranet.company.com, are typically hosted in internal DNS zones and are not published to public DNS. If a client sends these queries to a public DoH resolver that has no access to the organization's private zones, the resolver cannot return the internal DNS records. The result may be an NXDOMAIN response or another resolution failure, making internal applications and services unreachable from that client.
This does not apply when an organization operates or configures an internal DoH resolver with access to its private DNS zones. The issue is specifically the use of external resolvers that are outside the organization's DNS infrastructure.
DNS-based security controls can be bypassed
Many enterprise DNS security controls are enforced at the organization's recursive resolver. These can include malicious-domain blocking, DNS filtering, policy enforcement, and query logging for threat detection. When a client sends queries directly to an external DoH resolver, those queries no longer pass through the internal resolver, so controls implemented there cannot be applied to them.
This can create a gap in DNS security visibility and policy enforcement. Organizations may need additional endpoint, network, or browser controls to ensure that clients use approved DNS resolvers.
DNS monitoring can lose visibility
Enterprise DNS monitoring often depends on query and response data collected from internal DNS resolvers. When clients use external DoH services, their DNS queries may not appear in those resolver logs, creating blind spots in DNS monitoring and analysis.
This can affect activities such as DNS availability monitoring, anomaly detection, troubleshooting, and correlation between DNS activity and other network data. The extent of the visibility gap depends on how the organization's DNS monitoring and endpoint controls are implemented.
Browser and operating system DoH can complicate control
Modern browsers and operating systems can support secure DNS settings that allow DNS queries to be sent through DoH. Depending on the platform, browser configuration, operating system policies, and network settings, clients may use DoH without following the organization's traditional DNS path.
This makes endpoint configuration an important part of enterprise DoH management. Organizations need to determine which DoH resolvers are approved, whether clients are allowed to use external DoH services, and how unauthorized DNS paths should be detected or blocked.
Deploying DoH in enterprise environments
Enterprises do not necessarily need to block DoH. A better approach is to bring encrypted DNS under centralized control by using an approved DoH resolver and managing how clients access external DoH services.
- Use an internal DoH resolver: Deploy a DoH-capable internal resolver so clients can use encrypted DNS while continuing to resolve private domains and follow the organization's DNS security policies. This keeps DNS queries within the enterprise DNS infrastructure while providing encryption between clients and the resolver.
- Manage DoH through endpoint policies: Use browser and operating system policies to configure approved DoH resolvers or disable browser-managed DoH where necessary. This prevents applications from independently switching to external public resolvers and helps maintain a consistent DNS path.
- Block unauthorized external DoH when necessary: Organizations can use firewall and network security controls to restrict access to known external DoH services. Because DoH uses HTTPS, simple port-based blocking is not sufficient; organizations may need endpoint policies, destination-based controls, or other DNS security mechanisms to identify and restrict unauthorized DoH traffic.
DNS visibility with ManageEngine OpUtils
As encrypted DNS becomes more prevalent, enterprises need visibility into the DNS infrastructure that serves their clients.ManageEngine OpUtils helps monitor DNS availability and resolution across the network, including forward and reverse DNS resolution and IP-to-hostname validation using DHCP data.
OpUtils also provides DNS management for Microsoft DNS and AWS Route 53, allowing network teams to monitor and manage DNS infrastructure across on-premises and cloud environments from a single console. This helps teams identify resolution issues, validate DNS records, and maintain consistent DNS operations across their infrastructure.
Download a free 30-day trial or schedule a personalized demo to explore DNS monitoring and management with OpUtils.
FAQs on DNS over HTTPS (DoH)
What is DNS over HTTPS (DoH)?
DNS over HTTPS (DoH) is a protocol defined in RFC 8484 that sends DNS queries and responses through encrypted HTTPS connections, typically over port 443. Unlike traditional DNS, which commonly uses plaintext UDP or TCP on port 53, DoH protects the DNS exchange from being read or modified by parties observing the network path between the client and resolver.