What is DNS over HTTPS (DoH)? A Practitioner's Definition

Definition

DNS over HTTPS, or DoH, is a protocol that sends DNS queries through encrypted HTTPS connections rather than traditional unencrypted DNS on port 53. In practice, it helps hide which domain names a device is looking up from local network observers, while shifting more trust to the chosen DNS resolver.

How it works

To understand DoH, start with standard DNS. When your browser or operating system needs to reach example.com, it asks a DNS resolver for the IP address. Traditionally, that lookup is often sent in plaintext, which means a local Wi-Fi provider, ISP, or anyone with network visibility may be able to see the domain request.

DoH changes that transport layer.

Instead of sending a DNS packet directly to a resolver over port 53, the client sends the DNS request inside an HTTPS session, typically over port 443. That means the lookup is wrapped in the same encrypted channel used for normal web traffic.

At a high level, the flow looks like this:

A client needs to resolve a domain name.
The client sends the DNS request to a DoH-capable resolver.
The request travels over HTTPS, encrypted with TLS.
The resolver returns the DNS answer inside the HTTPS response.
The client uses that answer to connect to the destination service.

This has a few practical effects:

Local observers lose easy visibility into DNS queries.
DNS traffic blends in with normal HTTPS traffic.
Network-based DNS filtering may stop working unless specifically integrated with the DoH resolver.
The resolver operator still sees your DNS requests, so DoH improves confidentiality in transit, not anonymity.

For practitioners, the important distinction is that DoH protects DNS between the endpoint and the resolver. It does not magically make browsing private from every party involved.

When you’ll encounter it

You are most likely to encounter DoH in four places: browsers, operating systems, mobile devices, and enterprise networks.

Web browsers

Modern browsers have been one of the biggest drivers of DoH adoption. Some browsers can automatically enable DoH, upgrade to a compatible provider, or let users choose a trusted resolver manually.

That matters because the browser may no longer use the DNS settings you expect from the local network. If you run DNS filtering, split-horizon DNS, or internal-only name resolution, browser-level DoH can create troubleshooting headaches.

Typical symptoms include:

Internal hostnames fail to resolve in the browser but work elsewhere
Security filtering based on DNS stops catching requests
Web traffic works differently on managed vs unmanaged endpoints
Users bypass local parental control or SMB web filtering setups unintentionally

Operating systems and mobile platforms

Some operating systems support encrypted DNS natively and may allow DoH to be configured at the system level. On managed endpoints, this can be a benefit if you want consistent encrypted DNS across all applications, not just the browser.

On the other hand, if users can set custom resolvers freely, you may lose centralized visibility and control.

Public Wi-Fi and untrusted networks

This is where DoH is easiest to justify. On hotel, airport, café, and conference Wi-Fi, encrypted DNS reduces passive exposure of domain lookups to the local network operator or anyone monitoring traffic nearby.

It is not a replacement for a VPN, but it does close one common privacy gap.

Enterprise and SMB environments

In business networks, DoH is a tradeoff. It can improve confidentiality, but it can also interfere with:

DNS logging for investigations
DNS-layer malware blocking
Data loss and egress monitoring
Split-DNS for internal applications
Policy enforcement based on approved resolvers

For many organizations, the right answer is not “disable DoH everywhere” or “enable DoH everywhere.” It is to standardize it through approved resolvers, endpoint policies, secure web gateways, or DNS security platforms.

Should you use it?

Usually, yes for privacy-conscious users and unmanaged devices, and yes with controls for managed environments.

Use DoH when:

You want better privacy on public or untrusted networks
You do not trust the local network to handle DNS appropriately
You want to reduce trivial DNS snooping
You have selected a reputable resolver with a privacy posture you accept

Use caution when:

You rely on local DNS filtering or logging
Your organization uses internal-only domain names
You need split-horizon DNS for hybrid apps or VPN access
Browser-managed DoH conflicts with enterprise policy

For security teams, the key question is not just whether DoH is “good” or “bad.” It is who controls the resolver path.

If your endpoints use arbitrary third-party DoH resolvers, visibility drops and policy enforcement may weaken. If your environment manages DoH centrally, it can be a net positive.

Practical checks for admins

If you suspect DoH is affecting name resolution or security controls, verify which resolver path a device is actually using.

Technical Notes

Check browser DNS behavior and system resolvers:

nslookup example.com
dig example.com
resolvectl status

Test whether a known DoH endpoint is reachable:

curl -I https://dns.google/dns-query
curl -I https://cloudflare-dns.com/dns-query

Query a DoH resolver directly with curl:

curl -H 'accept: application/dns-json' \
  'https://dns.google/resolve?name=example.com&type=A'

A successful response typically returns JSON with answer records:

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "Answer": [
    {
      "name": "example.com.",
      "type": 1,
      "TTL": 163,
      "data": "93.184.216.34"
    }
  ]
}

Indicators that DoH may be bypassing local controls include:

Browser resolves domains differently from nslookup
DNS logs on the local resolver suddenly drop
HTTPS connections appear to DoH endpoints over port 443
Internal domains fail only in browser-based workflows

If you manage endpoints, review browser policies and OS encrypted DNS settings before assuming your network DNS policy is being followed.

DNS

The Domain Name System translates domain names like example.com into IP addresses that systems use to connect.

DoT

DNS over TLS (DoT) also encrypts DNS, but uses a dedicated TLS connection, commonly on port 853, instead of HTTPS. It is easier to identify on the network than DoH.

Traditional DNS

Standard DNS usually refers to plaintext DNS queries over UDP or TCP port 53. It is widely compatible but offers little privacy in transit.

DNSSEC

DNSSEC helps verify the authenticity and integrity of DNS answers. It does not encrypt DNS traffic. DNSSEC and DoH solve different problems and can be used together.

Split DNS

A setup where internal users get different DNS answers than external users for the same domain. This is common in enterprise environments and one reason unmanaged DoH can cause problems.

Secure DNS resolver

A DNS provider or platform that supports encrypted DNS, logging controls, filtering, and sometimes threat intelligence or policy enforcement.

Bottom line

DoH is best understood as encrypted transport for DNS, not a complete privacy or security solution. It is useful, especially on untrusted networks, but it changes where trust and control sit.

If you are an individual user, enabling DoH is often a sensible privacy upgrade. If you are an admin, use it intentionally, through approved resolvers and endpoint policy, so you keep the benefits without losing visibility or breaking internal DNS behavior.

For further information, you may also want to check out our articles on what is a typosquatting attack and CVE-2026-7465.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.