What Is DNS Over HTTPS and Why It Matters

You type a familiar address into your browser, press Enter, and the page appears almost instantly. Behind that simple action, your device first has to ask a naming service where the website lives. The request usually happens without user intervention, before the browser can connect to the destination, and the network may be able to see the domain being requested even though the page itself uses HTTPS.

That is why DNS over HTTPS, or DoH, matters. It encrypts DNS queries by carrying them inside ordinary HTTPS exchanges. The change improves privacy, but it also creates practical complications. Local filtering can stop working, administrators lose some visibility, and users may depend more heavily on a remote resolver. Understanding what DoH changes, and what it doesn't, is more useful than treating it as a universal privacy switch.

The Invisible Lookups Shaping Your Browse Session

You open a news site from a coffee shop. The page loads its main address, then requests images, advertising systems, analytics services, fonts, video platforms, and other resources. Before each connection can begin, your device often needs to translate a human-friendly domain name into an IP address. That translation is DNS, the internet's directory service.

Traditional DNS sends those questions through a path that isn't encrypted. A network operator, access provider, or other intermediary positioned along the route may be able to observe the domain names requested. They won't necessarily see the full contents of an HTTPS page, but the DNS trail can still reveal which services your device is trying to reach.

The important distinction: HTTPS can protect the page you read while traditional DNS leaves the name of the destination exposed.

DNS over HTTPS changes the transport, not the purpose of DNS. Your browser still asks a resolver to translate a domain into an address. The difference is that the query and response travel inside an HTTPS connection, using the same general encrypted framework that protects normal web traffic. The resolver can answer the question, while casual observers on the network have a much harder time reading the request.

The result is especially relevant on networks you don't control. A hotel, airport, school, or internet provider still carries your traffic, but it no longer receives DNS names in the same simple cleartext form from a DoH-enabled client. That doesn't make you anonymous, and it doesn't conceal every signal created by browsing. It does address one exposed part of the connection process.

For practical technology reporting and explainers about the systems behind everyday devices, NeoTeo's technology coverage offers a useful place to continue exploring how these layers fit together.

DNS is a directory, not the destination

A DNS request doesn't contain the article, image, or account page you're trying to load. It asks, in effect, “Which network address belongs to this domain?” Your browser then uses the answer to establish another connection.

That distinction prevents a common misunderstanding. DoH doesn't encrypt all web activity by itself. It protects the exchange used to resolve names. HTTPS must still protect the application traffic that follows, and other information, such as connection metadata, may remain visible to parts of the network.

How DNS Over HTTPS Actually Works

RFC 8484 defines DoH as a way to carry DNS queries and responses through HTTPS. The standard maps each DNS query-response pair into an HTTP exchange, rather than sending the DNS message through the traditional cleartext path. Because the exchange uses HTTPS, it can typically travel over port 443, the port commonly associated with ordinary secure web traffic. The IETF specification for DNS over HTTPS describes the protocol's precise request and response behavior.

The process is easier to understand as a short chain:

1. You enter a domain in the browser.
2. The browser prepares a DNS question.
3. It sends that question to a DoH resolver through an HTTPS connection.
4. The resolver returns the DNS answer inside the encrypted exchange.
5. The browser connects to the returned address.

What the HTTPS layer contributes

TLS gives the connection confidentiality, so observers can't casually read the DNS message in transit. It also provides integrity, which helps prevent an intermediary from changing the request or response without detection. Server authentication helps the client verify that it has established an encrypted connection with the intended resolver endpoint.

DoH also uses familiar HTTP behavior. The protocol can take advantage of HTTP features such as content negotiation and caching, which lets DNS messages move through a web-oriented transport instead of requiring an entirely separate encrypted network system. The RFC 8484 technical text explains how DNS messages fit into HTTP exchanges.

The use of HTTPS has an operational consequence. A network device can identify that encrypted web traffic is moving through the connection, but distinguishing a DoH exchange from every other HTTPS exchange becomes more difficult than inspecting a dedicated, plainly identifiable DNS channel. That makes indiscriminate blocking harder, although organizations can still use policies, endpoint controls, resolver management, and other traffic controls.

The protocol's design also supports controlled access to DNS information through browser and HTTP APIs, including Cross-Origin Resource Sharing. That matters to developers because DoH isn't merely a tunnel for an operating system's resolver. It was designed to fit into the web's existing application environment, as described in this RFC 8484 design overview.

A short visual explanation can make the sequence easier to remember:

The encrypted connection protects the DNS exchange from ordinary on-path inspection. It doesn't eliminate the need to choose a resolver carefully, because the resolver receiving the query remains part of the trust model.

Traditional DNS Versus Encrypted DNS Alternatives

DoH isn't the only way to protect DNS in transit. The main alternatives differ in where encryption happens, how recognizable the traffic is, and how easily an administrator can apply local rules.

Traditional DNS is straightforward and widely supported, but its queries are sent without transport encryption. DNS over TLS, or DoT, encrypts DNS through TLS while using a dedicated protocol path. DNS over HTTPS also encrypts the exchange, but places DNS inside HTTPS, allowing it to blend more naturally with regular web traffic.

DNS Transport Options Compared

Transport	Encryption	Port	Visibility	Typical Use Case
Traditional DNS	None at the transport layer	Standard DNS port	Easy for network tools to identify and inspect	Legacy compatibility, local control, and environments that require direct DNS visibility
DNS over TLS	TLS encryption	Dedicated encrypted-DNS port	More distinct from ordinary web traffic	Managed networks that want encryption with a recognizable DNS channel
DNS over HTTPS	HTTPS and TLS encryption	Typically port 443	Blends with other HTTPS traffic and is harder to inspect by DNS-aware devices	Browser privacy, public networks, and clients that need resistance to simple DNS interception

The comparison reveals why no option wins in every environment. Traditional DNS gives administrators the clearest view and often fits existing filtering systems, but it exposes the names being requested. DoT protects the content of DNS exchanges while preserving a more recognizable transport identity. DoH hides the DNS message inside HTTPS, which improves resistance to basic blocking and interception but makes local classification more difficult.

The choice depends on who manages the network

A person using a personal laptop on an untrusted network may value DoH because it reduces exposure of DNS names to nearby intermediaries. A company managing its own resolver may prefer encrypted client-to-resolver traffic that still passes through an approved internal policy layer. In that arrangement, the organization can retain control by operating or explicitly approving the resolver rather than allowing every browser to select its own public service.

For families, schools, and businesses, the question isn't only “Is the connection encrypted?” It is also “Who gets to decide which domains resolve?” DoH can move that decision away from the local network if a browser selects an external resolver independently. The same privacy feature that protects a user from local inspection can bypass a local rule that someone intentionally configured.

The Privacy Versus Observability Trade-Off

A browser on a company laptop opens a website, but its DNS request never reaches the company's resolver. The browser sends that question through HTTPS to an external resolver instead. The domain name is harder for nearby observers to read, while the company's filtering and investigation tools may lose the signal they were built to monitor.

That is the central tension behind DoH. Encryption protects DNS names from passive observers, yet it can also hide those names from the administrator responsible for the device or network.

An enterprise resolver may block dangerous destinations, enforce acceptable-use rules, record requests for incident analysis, or direct internal names to internal services. If a browser chooses an external DoH resolver, those requests can bypass the organization's normal control point. Mozilla explains this in its Firefox DNS over HTTPS guidance, including how local DNS policies can be bypassed and how enterprise administrators can disable DoH.

The result is a privacy versus observability decision, not a universal security upgrade. DoH protects information from one observer while removing useful information from another. A school, family, or business may need DNS visibility for safety and policy, while a person on an untrusted network may want to prevent that network from reading DNS requests.

Performance is more nuanced than a speed claim

Encrypted DNS adds connection work. The client must establish or reuse HTTPS and TLS connections, and the resolver must process each request through that transport. Research has found that individual DNS lookups can take longer than traditional DNS. A study of DNS privacy mechanisms and browsing performance found that DNS over HTTPS did not noticeably increase complete page-loading times, even though the lookup itself can carry extra overhead.

A slower lookup therefore does not automatically create a visibly slower website. Browsers cache answers, reuse connections, and perform other loading tasks at the same time. Users may encounter a policy conflict or an unreachable resolver before they notice a meaningful speed difference.

Adoption isn't the same as reliable deployment

Encrypted DNS has moved beyond the experimental stage, but deployment remains uneven and can plateau. One 2026 measurement set reported that 12.9% of queries to 1.1.1.1 were encrypted overall, with about 6.2% using DoH and 6.7% using DNS over TLS, according to Google's secure transport documentation. The figures show real adoption without showing that encrypted DNS has replaced traditional resolution.

Another measurement found global DoH usage stayed nearly flat through 2025 at about 13.91% of handshakes, while only about 64% of clients kept DoH active where it had been deployed. The measurement study on DoH deployment behavior points to practical friction: clients can fall back, lose the setting, or partially disable DoH without producing an obvious failure.

Resolver choice also concentrates DNS data in the selected service. For users judging privacy beyond transport encryption, the provider's data-handling rules matter too. Simsima's privacy commitment illustrates the policy language users should examine before trusting a service with personal information.

How to Enable or Disable DNS Over HTTPS

The control may sit in the browser, the operating system, or both. A setting called “secure DNS” also varies by product. Start with the application that performs the lookup, then check whether device management, network policy, or parental controls can override that choice.

Firefox

Open Firefox Settings, select Network Settings, and open the connection settings control. Find Enable DNS over HTTPS, then switch it on. Firefox lets you choose an available provider or enter an approved custom provider. To turn DoH off, clear the same option and save the change.

Firefox treats DoH as one part of a larger policy system. An organization can apply a rule that disables it, and the browser may turn it off when it detects parental controls. The result can look like a failed setting, but the browser is giving local administration and safety controls priority over an individual preference.

Chrome

In Chrome, open Settings, choose Privacy and security, and select Security. Find Use secure DNS, then choose whether Chrome should use the current service or a provider you select. Turn the option off when a work or school network requires DNS requests to stay with its local resolver.

Encrypted DNS reached browsers through a gradual rollout. Google Public DNS offered an encrypted option before the formal standard was published. Google and Mozilla were testing implementations by March 2018, RFC 8484 appeared on October 19, 2018, Firefox enabled DoH by default for many U.S. users in February 2020, and Chrome began a default rollout in May 2020. These milestones show why browser controls can differ even when they appear to offer the same feature.

Windows and managed devices

Modern operating systems may provide encrypted DNS options in the network settings for an active Wi-Fi or Ethernet connection. Select an encrypted mode only after checking the network's requirements. A browser setting usually covers that browser's lookups, while an operating-system setting can affect several applications.

A successful toggle does not prove that DoH is active. Recheck the browser's secure DNS status, identify the resolver in use, and test from the network where you will browse. A work policy, parental-control service, fallback behavior, or unsupported resolver can leave DoH inactive despite an enabled preference. For related device setup advice, see NeoTeo's phone guides.

What You Should Decide Before Switching to DoH

You connect to airport Wi-Fi, open a familiar site, and notice that the browser's DNS requests no longer travel through the network's usual resolver. That change can block a local observer from reading those lookups, yet it may also bypass the filtering system that keeps a workplace or family network under control.

The decision depends on which observer you want to exclude, which resolver you trust, and which local controls must continue working. DoH can suit personal use on public or shared networks when reducing local DNS exposure matters more than network filtering. It protects the DNS path from intermediaries that could inspect cleartext queries. The resolver still receives the query, DoH does not make browsing anonymous, and it does not replace HTTPS.

For a company, an unmanaged browser setting can create operational friction. Security teams may lose DNS-based blocking, reporting, and incident clues when browsers send requests to outside providers instead of the organization's approved resolver. A managed configuration can keep encryption while directing devices to an internal or enterprise resolver. That approach preserves policy control, although adoption can plateau when browsers, operating systems, resolvers, and fallback rules do not align.

Resolver concentration deserves attention

Encryption changes who can read a DNS request locally. It does not remove dependence on the resolver handling that request. Resolver-measurement research found that 93% of DDR resolvers shared identical configurations pointing clients to major cloud DNS providers, raising concentration concerns as encrypted DNS expands. The finding appears in the DDR resolver measurement study. A private connection to a resolver can therefore reduce local observation while increasing reliance on a small group of remote providers.

Use this decision framework:

• Choose DoH for personal privacy: Enable it when local DNS observation is the larger concern and filtering is not required.
• Use managed encryption at work: Direct clients to an approved resolver and retain security inspection where policy requires it.
• Test fallback behavior: Verify that the browser stays encrypted instead of falling back to traditional DNS.
• Review resolver trust: Check retention and privacy policies before treating encryption as complete privacy.

For browser policy and security requirements, consult this guide to the best browser for UK businesses. For help investigating device, browser, or network behavior, use NeoTeo's contact page.

NeoTeo publishes practical tutorials and security explainers about protocols such as DNS over HTTPS. Visit NeoTeo for technology coverage and guidance on privacy and network control.