What Is DNS over HTTPS (DoH) and DNS over TLS (DoT)?

DNS is one of those pieces of internet plumbing that usually “just works” until you start looking closely at privacy, security and compliance. Then you realise something uncomfortable: classic DNS queries are sent in clear text, revealing every hostname your users and servers look up. Over the last few years, DNS over HTTPS (DoH) and DNS over TLS (DoT) have emerged to fix exactly this problem by encrypting DNS traffic in transit. For hosting teams, developers and IT managers, this is not an abstract browser feature; it directly affects how you debug DNS, design network policies and plan your hosting infrastructure.

In this article, we will unpack what DoH and DoT actually are, how they differ from each other and from DNSSEC, what privacy and security gains they bring, and where their limits are. We will also look at their impact on hosting environments: shared hosting, VPS, dedicated servers and colocation. As dchost.com, we will keep the focus on real-world implications you will feel in your daily operations: logging, monitoring, troubleshooting, corporate policies and customer support.

Classic DNS in Plain Text: The Problem DoH and DoT Try to Solve

Before talking about encryption, it helps to quickly revisit how traditional DNS works. When a browser or server wants to reach example.com, it performs a DNS query. Typically this looks like:

• Your device asks the configured resolver (often your ISP, a local resolver on your network, or a resolver run by your hosting provider).
• That resolver talks to the DNS hierarchy: root servers → TLD servers → authoritative nameservers for the domain.
• The resolver returns the final IP address to your device and often caches it for a while.

In classic DNS, these queries and responses travel mostly over UDP or TCP on port 53, in clear text. Anyone on the path – local Wi‑Fi users, corporate network equipment, your ISP, or a malicious actor who can tap the connection – can see which domain names are being looked up. They cannot directly see what you do on the site (HTTPS still protects that), but they get a detailed log of which hostnames you visited, and when.

On top of that, unauthenticated DNS is susceptible to spoofing and manipulation. That is where technologies like DNSSEC enter the picture, providing authenticity and integrity for DNS data. If you are not yet familiar with it, we have a separate deep dive on what DNSSEC is and when you should enable it. DoH and DoT address a different (but related) problem: confidentiality of DNS traffic in transit.

What Is DNS over HTTPS (DoH)?

DNS over HTTPS (DoH) is a protocol that sends DNS queries over standard HTTPS (usually port 443), instead of plain UDP/TCP on port 53. In simple terms, your DNS lookups are wrapped inside normal HTTPS requests to a DoH server.

At a high level, the flow looks like this:

1. Your browser or operating system is configured to use a DoH resolver.
2. When it needs to resolve a hostname, it creates an HTTPS request to the resolver’s URL (for example, https://resolver.example.net/dns-query).
3. The DNS question is encoded inside that HTTPS request, often using the DNS wire format and the application/dns-message content type.
4. The DoH resolver processes the request, performs the recursive DNS resolution if needed, and sends the answer back inside the HTTPS response.
5. Your browser/OS decodes the DNS message and uses the IP address as usual.

Because everything rides on HTTPS:

• The DNS query and response are encrypted in transit using TLS.
• To the network, DoH traffic looks like any other HTTPS request to that resolver host.
• Middleboxes, ISPs or Wi‑Fi hotspots cannot easily see which hostnames you are resolving, only that you are talking to a specific DoH endpoint.

Why Browsers Love DoH

DoH became widely known because major browsers introduced support for it and in some cases enabled it by default with specific resolvers. From the user’s perspective, this has a few benefits:

• Privacy from local networks: Administrators of coffee shop Wi‑Fi, hotels or even some corporate networks can no longer trivially inspect DNS queries in clear text.
• Resistance to basic DNS injection: Simple on-path manipulation of port 53 traffic (to inject ads, block certain domains, etc.) is much harder when queries are encrypted inside HTTPS.
• Single security model: DNS queries and web content now share the same TLS-based channel and certificate validation logic.

However, this design also has consequences. Network administrators lose some visibility and control they used to have at the DNS level. For example, internal DNS-based filters, family-safe resolvers or split-horizon setups can be bypassed if an application hardcodes its own DoH resolver.

DoH from a Hosting Perspective

From the point of view of your website and your hosting infrastructure at dchost.com, DoH has two important characteristics:

• Authoritative DNS is not directly changed. Your domain’s authoritative nameservers still receive standard DNS queries over UDP/TCP; the DoH part happens between the client and their chosen resolver.
• Client behaviour may differ. If a browser or system uses a remote DoH resolver instead of the local resolver you control, some of your assumptions about DNS-based controls, logging and troubleshooting change.

This means you do not need to rewrite your DNS zone files to “support DoH”. But you should understand that many of your visitors’ queries might reach your nameservers via large public resolvers that terminate DoH/DoT, rather than via ISP resolvers or your own recursive infrastructure.

What Is DNS over TLS (DoT)?

DNS over TLS (DoT) is another standard for encrypting DNS queries, but instead of hiding them inside HTTPS, it places DNS messages inside a dedicated TLS tunnel, usually on port 853.

Conceptually, the steps look like this:

1. The client (your OS, a DNS forwarder, or a recursive resolver) initiates a TLS handshake to the DoT server (resolver) on port 853.
2. Once the TLS session is established, the client sends classic DNS messages inside that encrypted channel.
3. The DoT server resolves the queries and sends responses back over the same TLS connection.

Key points about DoT:

• It keeps DNS as DNS, only wrapped in TLS; there is no HTTP layer.
• It uses a dedicated port (853), which makes it easy to identify and filter at the network level if desired.
• It is often used between devices and resolvers, and between resolvers themselves (for example, a forwarding resolver talking to an upstream), rather than directly inside user applications.

DoT is particularly attractive in infrastructure and ISP environments: you want encrypted DNS, but you also want clear separation from web traffic and predictable behaviour for firewalls and monitoring tools.

DoH vs DoT: Key Differences and Trade-Offs

Both DoH and DoT encrypt DNS queries with TLS. The most important differences are in integration, network behaviour and operational control.

In practice, many organisations use a mix: DoT between internal resolvers and upstream providers, and DoH primarily on end-user devices or where HTTP-based integration is convenient.

How DoH/DoT Compare to DNSSEC and Other Security Measures

One of the most common misunderstandings we see in support tickets and architecture discussions at dchost.com is the idea that DoH/DoT “replace” DNSSEC. They do not. They solve different parts of the problem.

• DoH/DoT: Encrypt DNS traffic in transit so that on-path observers cannot easily see or modify queries and responses.
• DNSSEC: Cryptographically signs DNS records so that the client can verify that the data came from the legitimate authoritative source and was not tampered with, even if the transport path was not trusted.

You can (and often should) use both together. A realistic layered approach looks like this:

• Run DNSSEC for your domains so that resolvers can validate the authenticity of your DNS data.
• Use DoT or DoH between clients and resolvers, and between resolvers and upstream servers, to protect DNS queries against passive monitoring and trivial injection.
• Harden your web stack with modern TLS and HTTP security headers, as described in our guide on HTTP security headers such as HSTS, CSP and X-Frame-Options, and our articles on TLS/SSL best practices.

Even with DoH/DoT, a malicious or misconfigured resolver can still lie to clients. That is where DNSSEC validation becomes crucial. Likewise, even with DNSSEC, plain-text DNS leaks metadata; DoH/DoT fix that part.

Privacy and Security Benefits in Real Life

Let’s move beyond theory and look at what changes when you adopt DoH/DoT, either as a user, as an organisation, or inside your hosting environment.

What Attackers and Intermediaries Can No Longer See

With classic DNS, any on-path observer can:

• See every hostname you look up in clear text.
• Correlate timestamps and IPs to build a detailed browsing profile.
• Inject fake responses or block lookups for certain hostnames.

With DoH or DoT in place between the client and resolver:

• The hostname being resolved is encrypted inside the TLS tunnel.
• Observers only see that you are talking to a DoH/DoT server, not which domains you are resolving.
• Simple DNS injection based on port 53 becomes ineffective; an attacker would have to compromise the resolver or break TLS.

This is especially valuable on untrusted networks (public Wi‑Fi, hotels, conferences) and in environments where DNS is used for censorship or traffic shaping.

What Stays the Same (Limits of DoH/DoT)

There are also things DoH and DoT do not fix:

• Your resolver still sees everything. The DoH/DoT operator can log all queries. You are shifting trust from the network path to the resolver.
• IP-based metadata remains. Even if DNS is encrypted, observers can still see which IP addresses you connect to. For some services, this alone reveals a lot.
• DNS authenticity is separate. Without DNSSEC validation, a compromised or malicious resolver can still forge answers.
• Application-level tracking is unchanged. Cookies, browser fingerprints and other web tracking mechanisms are not touched by DoH/DoT.

From a compliance perspective (GDPR, KVKK and similar regulations), DoH/DoT are only one piece of the privacy puzzle. The way you store and anonymise logs on your servers still matters a lot. For that side, we recommend reviewing our article on log anonymisation and IP masking techniques for KVKK/GDPR‑compliant hosting logs.

Impact on Hosting Infrastructure

Now let’s talk about where DoH/DoT intersect with the services we run and manage every day at dchost.com: shared hosting, VPS, dedicated servers and colocation.

Authoritative DNS: Almost Business as Usual

If you host your domains with us and use our nameservers, your zone files and authoritative DNS configuration do not need to change just because clients start using DoH/DoT. The encryption happens between the client and their resolver, not between the resolver and your authoritative nameservers.

The main differences you might notice over time are:

• Changing resolver mix: More queries might come from large public resolvers that provide DoH/DoT to end users, rather than from ISP resolvers.
• Different caching patterns: Some resolvers use aggressive caching, QNAME minimisation or ECS (EDNS Client Subnet) differently. This can slightly change how fast DNS changes propagate in the wild, but the fundamental rules of TTLs remain the same.

If you need a refresher on how DNS records, TTLs and gotchas work, our article DNS records explained like a friend is a good companion to this piece.

Recursive Resolvers on VPS/Dedicated Servers

Many advanced customers run their own recursive resolvers on VPS or dedicated servers – for example, a local Unbound or BIND instance used by multiple application servers in a private network. Here, DoT and DoH become active design choices:

• Upstream encryption: You can configure your resolver to talk to upstream providers over DoT, keeping DNS encrypted between your network and the outside world.
• Internal DoT for clients: You can expose DoT on your own resolver so that internal clients (office networks, other servers, containers) use encrypted DNS within your infrastructure.
• DoH gateways: In some architectures, you might deploy a DoH endpoint that forwards requests to an internal resolver. This lets browsers and applications talk HTTPS while you keep DNS logic under your control.

This is a typical scenario for customers using our VPS, dedicated server and colocation services: you get full root access and network control to build a DNS architecture that fits your security and compliance requirements.

Monitoring, Logging and Compliance

When you start encrypting DNS inside your network with DoT/DoH, the place where you can observe and log DNS queries shifts towards your resolvers. For hosting teams, that means:

• Less visibility on raw network taps: Packet captures on intermediate switches and firewalls no longer show DNS payloads; you see only TLS sessions.
• More importance for resolver logs: If you need DNS query logs for debugging, analytics or security, you must design them at the resolver level (and handle them carefully for privacy and regulatory reasons).
• Careful data retention: Encrypted DNS is good for privacy on the wire, but if you log every query with full IPs and hostnames, you may create a more sensitive dataset. That ties back to the log anonymisation practices mentioned earlier.

On shared hosting plans, this level of DNS logging is typically centralised and handled by us. On VPS/dedicated/colocation, you decide how much you log and how long you keep it, but we strongly recommend aligning it with your organisation’s KVKK/GDPR policies.

Network Policies and Firewalls

From a network-security point of view, DoH and DoT change how you enforce DNS-related policies:

• With DoT: You can allow outbound TCP/853 only to your chosen resolvers and block the rest. This forces clients to use the resolvers you trust while still giving them encrypted DNS.
• With DoH: It becomes harder to distinguish DNS traffic from generic HTTPS on port 443. You may need more advanced firewall rules (SNI-based, IP-based, or using TLS inspection where legally and ethically appropriate) if you want to block unauthorised DoH endpoints.
• For servers in data centres: Many organisations simply restrict all outbound access from production servers and explicitly allow only specific resolvers and service endpoints. In such setups, controlling DoT is straightforward; controlling DoH requires tighter egress rules on HTTPS traffic.

On our VPS and dedicated servers, you can implement these strategies directly in your firewall (for example using ufw, firewalld, iptables or nftables), as covered in our guide on firewall configuration on VPS servers.

DNS Troubleshooting Gets a New Twist

DoH and DoT also change how you troubleshoot DNS issues when something does not resolve as expected.

Some common scenarios we increasingly see:

• You change a DNS record, flush local caches, but your browser still resolves the old IP. It turns out the browser is using a built-in DoH resolver with its own cache, independent of the system resolver.
• A corporate network has internal DNS zones (for example, internal.example.local). Some users cannot resolve them because their browsers are configured to use a public DoH resolver that has no knowledge of internal records.
• From your VPS, dig shows the correct DNS answer, but a user’s laptop does not. The difference is that your VPS queries your hosting resolver directly, while the laptop goes through an external DoH resolver that has not yet refreshed its cache.

When debugging DNS today, always ask:

• Which resolver is the client actually using?
• Is that resolver reached over classic DNS, DoT or DoH?
• Does that resolver see the same data as your authoritative nameservers?

Our detailed guides on DNS behaviour, such as why DNS propagation can take time and how to speed it up, and our troubleshooting article on fixing DNS_PROBE_FINISHED_NXDOMAIN and other DNS errors, become even more relevant in a world where multiple resolvers and protocols coexist.

DNS Strategy: Registrar DNS, Hosting DNS, Cloud DNS

DoH and DoT do not change the high-level decision of where to host your DNS (registrar, hosting provider, or a specialised DNS platform), but they do influence how much control you have over encrypted DNS behaviour. If you rely entirely on external resolvers and DoH endpoints, you may have less visibility and flexibility than if you also maintain your own resolvers as part of a broader DNS stack.

If you are considering how to design that stack, our article on Cloudflare DNS vs hosting DNS and nameserver strategy covers the trade-offs between registrar DNS, hosting DNS and third-party DNS providers, and how they fit together.

DoH/DoT for Website Owners: What You Should Actually Do

Most website owners and teams hosting with dchost.com do not need to roll out their own DoH/DoT infrastructure from day one. But there are several practical steps that make sense in 2025 and beyond.

1. Understand That Your Visitors Already Use Encrypted DNS

Modern browsers and operating systems increasingly use DoH/DoT by default, or at least provide easy toggles. Even if you do nothing, a portion of your visitors will be resolving your domain via encrypted channels. That is normal and generally positive for user privacy.

From your perspective, the key is to be aware of this when troubleshooting and when interpreting logs and analytics. The path from “user → resolver → your authoritative DNS → your web server” may involve more layers than before, but your core DNS and HTTP configuration remain the same.

2. Enable DNSSEC and Keep Your Zone Healthy

Since DoH/DoT do not verify DNS authenticity on their own, DNSSEC becomes more valuable, not less. By signing your zones and ensuring resolvers can validate them, you protect users even if a resolver or network path is compromised.

If your domains are registered or hosted with us, you can enable DNSSEC for many TLDs directly from the control panel. The setup details depend on your registrar and DNS provider, but the high-level process and operational tips are covered in our guide on DNSSEC deployment for domains and hosting.

3. Harden the Rest of the Stack: TLS and HTTP Security Headers

Encrypted DNS is only one part of end-to-end security. Once the DNS lookup completes, your visitors still need:

• Strong TLS configuration (TLS 1.2/1.3, modern ciphers, proper certificate management).
• Secure cookies, HSTS, CSP and other HTTP security headers.
• Application-level protections against XSS, SQL injection and other web vulnerabilities.

We regularly help customers tune their VPS and dedicated servers to support modern TLS and HTTP configurations. If you want practical, server-side guidance, start with our article on setting HTTP security headers correctly and then apply similar care to your TLS settings.

4. For Advanced Teams: Consider Internal DoT/DoH Architecture

If you are running multi-server environments (for example, multiple VPS, application clusters or a colocation rack), you may want to:

• Deploy an internal recursive resolver that speaks DoT to upstream providers.
• Expose DoT to your internal servers, so all DNS inside your network is encrypted and centralised.
• Optionally provide a DoH endpoint for internal applications that expect HTTPS-based DNS.

This kind of architecture is easier to manage on VPS, dedicated servers or colocation, where you have full control over the OS and firewall. It can also be integrated with central logging and SIEM solutions, while respecting privacy through careful log minimisation.

Summary and How dchost.com Fits In

DNS over HTTPS (DoH) and DNS over TLS (DoT) are not future proposals anymore; they are actively used by browsers, operating systems and resolvers. They encrypt DNS queries in transit, hiding domain lookups from on-path observers and making simple DNS injection attacks much harder. At the same time, they do not replace other mechanisms like DNSSEC, TLS or HTTP security headers; they sit alongside them as part of a layered security model.

For you as a site owner, developer or infrastructure engineer, the key shifts are in understanding where DNS queries flow, which resolvers are involved, and how that affects logging, compliance and troubleshooting. Your authoritative DNS zones, web server configuration and SSL certificates still need the same care as before, but the network between users and resolvers becomes less transparent and more privacy-preserving.

At dchost.com, our role is to provide the stable foundation this all runs on: reliable DNS hosting, secure shared hosting, flexible VPS and dedicated servers, and colocation for teams who want full control down to the rack. Whether you simply want your domain and website to resolve correctly for users using DoH/DoT, or you are planning your own encrypted DNS architecture on a VPS or dedicated server, we can help you design and operate it calmly and predictably. If you are reviewing your DNS, TLS or security posture this year, it is a good moment to also factor DoH and DoT into your hosting roadmap.