DNS over HTTPS: what it is and how it protects your queries

Alpha Guide » Computer Technology » DNS over HTTPS: what it is and how it protects your queries

When you type a web address, there's a component working behind the scenes to ensure you reach the correct site: the Domain Name System (DNS). DNS translates easy-to-remember names into IP addresses that computers can understand. It's convenient, yes, but for years it operated with a significant vulnerability: these queries traveled unencrypted. This is why DNS over HTTPS, also known as DoH, has become so prominent—an extra layer of protection that makes it harder for your internet service provider to track which domains you visit.

It's important to clarify one thing from the outset: DoH improves the privacy of DNS queries, but it's not a VPN, nor does it turn your entire connection into a secret tunnel . Throughout this article, we'll explore exactly what it is, why it has become popular, how to activate it in Chrome, Edge, and Firefox, its advantages and disadvantages, how it differs from DNS over TLS and a VPN, and the extent of its technical and practical limitations.

What is DNS and why does the traditional system fall short?

DNS servers are one of those components that almost no one looks at, yet they underpin a large part of online browsing. Their job is to link a domain name to the IP address of the corresponding server . When you visit a website, your computer doesn't understand letters: it needs an IP address to know which machine to connect to. Many routers come with DNS servers already configured by the internet service provider, which makes the process convenient, although it also leaves a visible trace for whoever controls that infrastructure.

The underlying problem is that traditional DNS queries are made in plain text and without protection . This opens the door to eavesdropping, man-in-the-middle attacks, and manipulation of the response. An internet service provider can learn which domains you query and when; an attacker on a shared network can try to intercept the request and return a fraudulent response. This technique is known as DNS hijacking and can ultimately lead you to a fake page, unwanted advertising, or a site designed to steal data. Governments and internet service providers have also historically exploited these weaknesses to implement censorship, block domains, or display additional advertising.

• Passive listening: Someone observes the queries and deduces which services or websites you frequent.
• Man-in-the-middle: The communication is intercepted and the response is modified to impersonate a server.
• Blocking and filtering: It prevents the resolution of certain domains in order to control access to content.

DNS over HTTPS: Encrypt the query so it's not visible to everyone.

DNS over HTTPS, or DoH, is a solution that leverages the HTTPS protocol to transmit DNS queries and responses in encrypted form . Instead of sending a clear DNS request, the device encapsulates it within a secure connection, typically using port 443, the same port used by secure websites. This protects both the query and the response, preventing an external observer from easily reading them.

For this to work, the DNS server being queried must also support Domain-based DNS (DoH ). Simply enabling an option in the browser isn't enough: the chosen resolver must adhere to this standard. The specification has been evolving and is still considered a developing technology, although since 2018 companies like Google and the Mozilla Foundation have been testing and integrating it. In addition to improved privacy, tests indicate that DoH can reduce latency and make queries faster, because it's not always necessary to resolve the entire domain, but only the minimum required portion.

Advantages of DoH: more privacy, less manipulation, and better performance

The most obvious advantage is security. Because they travel encrypted, DNS queries are much harder to spy on or modify . This complicates man-in-the-middle attacks, reduces exposure on public Wi-Fi networks, and prevents a local operator from clearly seeing which domains you're requesting. Since DoH traffic uses port 443, it blends in with other HTTPS connections and is difficult to distinguish from a normal web visit.

There are also performance reasons. DoH can reduce latency and speed up DNS communications thanks to changes in how names are resolved and better use of the cache. For example, the GET method of some APIs is designed to be cached more efficiently. In practice, this can translate into slightly faster browsing, although it's not a magic bullet and the difference isn't always noticeable. Furthermore, since it's implemented in the browser, the user doesn't have to wait for their internet service provider to activate it.

Drawbacks and debates: when encryption complicates life

Not everyone views Domain-based encryption (DoH) favorably. The same encryption that protects the user also makes network monitoring more difficult . Many parental control programs rely on inspecting DNS queries to determine which websites children are trying to access; with DoH, this task becomes much more complicated and may even be impossible. A similar situation exists for corporate network administrators, who lose visibility into the domains being queried and cannot enforce certain rules as easily.

Internet providers also lose the ability to monitor access and block specific domains at the behest of an institution. This generates a legitimate debate: some see it as a victory for privacy, while others consider it a control and management problem . In the case of DoT, it is also criticized for using its own recognizable port, which allows for the identification of DNS queries even without knowing exactly what is being asked. DoH avoids this clear signal by disguising itself within HTTPS traffic, but in return, network administrators are left with fewer tools to manage their communications.

How to enable DoH in Chrome, Edge, and Firefox

Enabling Domain Name System (DNS) in a modern browser is usually straightforward, especially if it's based on Chromium or Firefox. The option exists, although in some cases it's hidden in advanced settings menus . Before changing anything, it's important to understand that the browser only protects its own queries: other applications on the device may continue using a different DNS system if it's not also configured at the system level.

Google Chrome

In Chrome, the quick way is to type chrome://flags/#dns-over-https in the address bar. That takes you directly to Chrome's Flags or experimental features.You'll see an option called Secure DNS lookups selected; click on the dropdown menu that says Default and choose Enabled. Then you'll need to restart your browser for the change to take effect.

Microsoft Edge

In Chromium-based Edge, the process is virtually identical. Open your browser and type edge://flags/#dns-over-https in the search barYou'll enter Edge's Flags and the same Secure DNS lookups option will appear. Change Default to Enabled and restart the browser when prompted.

Mozilla Firefox

In Firefox, you don't need to go to Flags. Click the menu button in the upper right corner and select Options . In the General section, scroll to the bottom and click Network Settings. In the window that opens, check the box next to Enable DNS over HTTPS. You can then choose from providers like Cloudflare and NextDNS to perform encryption over HTTPS.

DNS over TLS (DoT): the other encrypted path

DNS over TLS, or DoT, is another way to protect DNS queries. Instead of using HTTPS, it uses TLS over a TCP connection and a standardized port, 853. TLS is the same security foundation as HTTPS, so the idea is similar: to create an encrypted tunnel in which only the two participants can decrypt and process the information. This makes man-in-the-middle attacks more difficult and prevents a third party from reading or manipulating the query.

DotT has its advantages, especially compared to traditional DNS, which offers no security measures. Encryption prevents cybercriminals from intercepting requests and also hinders certain censorship measures . However, it requires compatibility from both the client and the server. Several providers offer compatible servers, but using it on a desktop or laptop usually requires installing additional software; on modern Android, at least since Android 9, it's already integrated. Solutions exist for Windows and Linux, although they aren't always as transparent as one might like.

Among the drawbacks, many data protection experts criticize DoT for using a single, recognizable port. While it's impossible to know which website is being accessed, it is possible to detect DNS traffic . For some network administrators, this is useful because it allows them to maintain an overview of what's happening; for others, it's a signal they'd rather hide. Furthermore, DoT is not yet as widespread as traditional DNS, and its server-side adoption is limited. There are concerns that a few companies will increasingly concentrate DNS queries, potentially creating a kind of international monopoly.

DoH vs. DoT: Two ways to protect the same thing

The main difference between DoH and DoT lies in the port and how the traffic is disguised. DoT uses its own port, 853, while DoH uses 443 and blends in with normal HTTPS connections . This seemingly minor difference has sparked considerable debate. From a privacy perspective, the indistinguishability of DNS queries from other traffic is an advantage: if they aren't recognized, they can't be manipulated as easily. From a network management perspective, however, control is lost, and it becomes more difficult to implement security or filtering policies.

At its core, there are two visions. The IETF, the consortium that develops many internet standards, is behind DoT , while Google and the Mozilla Foundation have strongly promoted DoH. These aren't opposing technologies, but they do represent different ways of understanding privacy, network visibility, and the role of intermediaries. The choice between one and the other depends on what needs to be protected and who needs to manage the network.

DoH vs. a VPN: It protects the question, not the entire journey

DoH and a VPN often come up in the same conversations about privacy, but they don't do the same thing. DoH protects the name query; a VPN protects the path your data takes . The simplest way to understand this is to think of DoH putting a sensitive question in a sealed envelope, while a VPN makes the entire journey go through a private tunnel before returning to the public road. Both can improve privacy, but only one is designed to comprehensively cover the traffic of phones, tablets, and computers.

What does DNS do before a site loads?

Before your browser can load a website, your device needs to know its location. DNS works like a phone book, translating a website name into an IP address . This happens constantly: when you open a page, launch an app, update your email, or play a video. Most of the time it happens silently, and you don't notice it, which is great for convenience, but it also makes it easy to overlook as a privacy issue. Traditional DNS queries aren't encrypted, so your internet service provider, your employer, your school, a coffee shop's Wi-Fi, or a hotel network could see which domains your device is trying to reach. They don't see the full content of an HTTPS page, but they do get a pretty revealing outline of your activity.

A DNS query doesn't reveal every page you've viewed or everything you type into a form, but a list of domains can expose habits, interests, work tools, health research, or financial services . That's why encrypted DNS has become a useful privacy feature. It doesn't reveal everything, but it does reveal more than many people realize.

What does DoH hide and what does it reveal?

DoH sends DNS queries over HTTPS, the same encrypted protocol used by secure websites. The request leaves your device encrypted and arrives at a resolver that supports the standard . On public Wi-Fi, this can make it difficult for the network operator to inadvertently read your queries. If your internet provider manages DNS, switching to a DoH resolver can prevent them from seeing these queries in the usual way. Furthermore, if a network manipulates name resolution results, encrypted DNS can reduce some forms of manipulation.

Now, DoH hides the query, not the entire conversation. It might prevent some observers from clearly seeing the domain lookup, but it doesn't turn your entire internet connection into an encrypted tunnel . Once the device knows the IP address, the rest of the connection follows its normal path, unless another privacy tool changes that route. DoH doesn't hide your real IP address from the websites, apps, or services you connect to, nor does it make you appear to be in a different city or country. If you log into an account, the service knows it's you. If the browser has cookies, saved sessions, advertising identifiers, or a recognizable fingerprint, DoH doesn't erase those signals.

It also doesn't protect every application unless it's configured at the system level and the application respects that setting. One browser might use secure DNS while another application on the same device uses a different DNS path . Some apps manage their own network and don't always align with the system or browser settings. Therefore, DoH can create a false sense of complete protection: it improves the privacy of DNS queries, but it doesn't protect file transfers, messaging traffic, video calls, game connections, background syncing, or streaming applications the way a VPN would.

What does a VPN protect and what can't it hide?

A VPN protects a different part of your journey. It creates an encrypted tunnel between your device and a VPN server, routing your internet traffic through that server . Your internet service provider or local Wi-Fi network sees an encrypted connection to the VPN server, not a clear view of every site and service you connect to. Additionally, the VPN changes the public IP address that websites and apps see: instead of your home or mobile carrier's IP address, the destination sees the VPN server's IP address. This can reduce location-based tracking, help you bypass some ISP profiles, and make using public Wi-Fi safer.

A comprehensive VPN can protect browsers, streaming apps, email clients, cloud backup tools, messaging apps, games, and background services. It can also route DNS requests through the encrypted tunnel when properly configured , which is why it's a good idea to run a DNS leak test. That said, a VPN isn't magic. If you log into a social network, email account, streaming service, or online store, that service still knows who you are. It can hide your original IP address, but it doesn't anonymize your login. The same applies to anything you send directly: your name, email address, payment details, shipping address, photos, or messages.

Cookies and browser fingerprinting still matter. Apps can create similar problems through advertising identifiers, permissions, location access, Bluetooth scanning, nearby Wi-Fi names, and scanning tools. Malware is another tough hurdle because it can capture data before it even reaches the VPN tunnel . In short, a VPN hides and encrypts a lot of activity, but it doesn't disguise every digital fingerprint.

DoH and a VPN can be used simultaneously

Yes, they can be combined, but the ideal setup depends on how the device, browser, and VPN app handle DNS. In many cases, the simplest solution is to let the VPN handle DNS . A good app should send DNS queries through the encrypted tunnel so your ISP doesn't receive them directly. This way, you get DNS privacy as part of the VPN connection without having to adjust your browser settings separately.

The problem arises when the browser uses its own Domain Authority (DoH) configuration while the VPN attempts to manage DNS at the system level. Nothing might break, but confusion does occur : you might think all queries are going through the VPN, but in reality, the browser is sending some on its own to a different resolver. This is where a DNS leak test comes in handy. If, after connecting to the VPN, you see your ISP's DNS servers, something isn't working as expected; if you see servers associated with the VPN, the configuration is more likely working correctly.

When is DoH sufficient and when is a VPN advisable?

DoH can be sufficient when your primary concern is the basic privacy of DNS queries in your browser. On a trusted home network, enabling Secure DNS reduces plaintext exposure without requiring you to change your location or secure all your applications . It's also useful on networks where DNS filtering or manipulation is a concern, because traveling over HTTPS makes it more difficult to easily inspect or modify. This doesn't mean it bypasses all restrictions or is censorship-proof, but it is a significant improvement over unencrypted DNS. Furthermore, it's lightweight: you don't need to choose a VPN server or significantly change your routing, and you typically won't notice a significant impact on speed.

A VPN makes the most sense when you want device-wide protection, not just DNS lookups. This includes airports, hotels, schools, coworking spaces, cafes, and rental accommodations . On shared networks, you don't know who controls the router, who else is connected, or if someone is trying to intercept traffic. A VPN also helps when you don't want your ISP to build a profile of your browsing patterns: even though HTTPS protects page content, network metadata can still reveal useful patterns. Traveling is another clear example: a VPN can make your connection more consistent, protect you on unfamiliar networks, and make websites see the VPN server's location instead of your temporary local connection.

Technical details of the Google Public DNS DoH APIs

Google Public DNS offers two distinct DoH APIs. One is designed for RFC 8484 and accepts GET and POST requests at https://dns.google/dns-query; the other is a JSON API that only supports GET requests at https://dns.google/resolve . There is also a web interface at https://dns.google/ that displays JSON results in the browser, but it doesn't implement a full API. This interface should not be confused with the API URLs or with https://dns.google/query. The service does not support unsecured HTTP URLs, and DoH is also supported by Google's public DNS64 service, although in that case, only IPv6 is supported. Google's secure transport documentation includes curl examples and details on TLS, DoT, and DoH.

Available HTTP methods

The GET method can reduce latency because it caches more effectively. RFC 8484 GET requests must include a `?dns=` parameter with a Base64Url-encoded DNS message , and it is the only method supported by the JSON API. The POST method is also only available in RFC 8484 and uses a binary DNS message with `application/dns-message` in both the request and response bodies. The HEAD method is currently unsupported and returns a 400 Bad Request error. Other methods return 501 Not Implemented errors.

Status codes and errors

The API returns several HTTP codes that are worth knowing. A 200 OK indicates that the HTTP parsing and communication with the DNS resolver were successful ; the response body can be a binary DNS response or JSON depending on the endpoint, the Accept header, and the GET parameters. Note: an HTTP error can also be a DNS failure, so it's advisable to check the DNS response code, for example, the "Status" field of the JSON, for errors such as SERVFAIL, FORMERR, REFUSED, or NOTIMP.

• 301 Moved Permanently: The client must retry the request at the URL specified in Location. If the original request was POST, it should only retry with GET if the new URL specifies a DNS parameter; otherwise, it must repeat with POST. 302, 307, and 308 status codes may also appear, and DoH clients must handle all four. Permanent 301 and 308 status codes can be cached indefinitely. POST requests that receive a 307 or 308 status code must always be retried with POST.
• 400 Bad Requests: Problems parsing GET parameters or an invalid DNS request message. Most invalid DNS messages receive a 200 OK with FORMERR, but HTTP errors occur for unreadable messages without a Question section, with a QR code indicating a response, or with nonsensical combinations of codes.
• 413 Payload Too Large: The body of a POST RFC 8484 request exceeds the maximum message size of 512 bytes.
• 414 URI Too Long: The GET query header was too large or the dns parameter exceeded 512 bytes.
• 415 Unsupported Media Type: The POST body did not have the content type header application/dns-message.
• 429 Too Many Requests: Too many requests have been sent in a given period. The client must wait until the time specified in the Retry-After header.
• 500 Internal Server Error: Internal errors in the DoH service.
• 501 Not Implemented: Only GET and POST are implemented; the rest return this error.
• 502 Bad Gateway: The DoH service was unable to communicate with Google Public DNS resolvers. Trying a different address might work, but a more effective backup plan is to try another DoH service or switch to traditional DNS using UDP or TCP at 8.8.8.8.

Best practices for privacy and performance

DoH application developers should limit HTTP headers. Headers such as Cookie, User-Agent, and Accept-Language can reveal information about the client implementation and contribute to deanonymization . It's recommended to send only the headers necessary for DoH: Host, Content-Type (for POST requests), and, if needed, Accept. The User-Agent header should be included in development or test versions. It's also advisable to use EDNS padding options to shorten queries to common lengths and make traffic analysis more difficult. HTTP/2 padding is possible, but unlike EDNS padding, it doesn't generate padding in DoH server responses.

The POST method in RFC 8484 should only be used in privacy-sensitive applications or browser modes. Using POST reduces cache capacity and can increase latency, so it's generally not recommended . However, reducing cache size might be advisable for applications that want to prevent web app synchronization attacks aimed at discovering which domains the user has recently visited. The HTTPS approach also has practical advantages: HTTPS APIs are widely available and supported, simplifying implementation; an HTTPS service gives web apps access to all types of DNS records, avoiding the limitations of browser or operating system APIs that are typically limited to host-to-address lookups; and clients that implement HTTPS over UDP with QUIC can avoid issues like line-head blocking that occur with TCP. If you encounter a bug or want to request a new feature, you should report the DoH-related issue through the usual channels.

Common questions about DoH and VPN

One of the most frequently asked questions is whether it makes sense to use DoH when already using a VPN. It's possible, but the most practical approach is usually to let the VPN handle DNS and verify with a leak test that the queries are going through the correct channels. If the browser sends its own queries one way and the VPN another, you could be in for an unpleasant surprise.

Another common question is whether DoH prevents your internet provider from seeing which websites you visit. DoH hides DNS queries from many observers, but it doesn't remove all metadata or hide your IP address : your ISP can still see which IP addresses you connect to and other network information. For broader protection, you need a VPN or a combination of multiple privacy layers.

It's also worth asking whether DomainHost (DoH) is sufficient on public Wi-Fi. It can help prevent the network operator from easily reading your DNS queries, but it doesn't protect the entire connection or the traffic of all applications . In airports, hotels, and cafes, using a VPN is usually more comprehensive, especially if you don't know who controls the router or if other people are connected.

Domain Name System (DoH) and VPNs aren't direct rivals, but rather tools with different capabilities. DoH encrypts domain lookup and reduces the exposure of that part of the process; a VPN encrypts the path between your device and a server and changes the IP address seen by destinations . Neither makes you invisible: accounts, cookies, browser fingerprints, app permissions, malware, and any data you share directly can still identify you. But that doesn't make them useless. It simply means each has its role. DoH protects the address lookup; a VPN protects much more of the path your data takes.