Every time you type a URL into a browser, your device sends a DNS query to resolve that hostname into an IP address. For decades, those queries traveled across the internet in plain text, visible to your ISP, network administrators, and anyone positioned to intercept traffic on the wire. DNS over TLS, commonly abbreviated as DoT, fixes that by wrapping DNS traffic inside an encrypted TLS tunnel — the same encryption technology that protects your bank's website. If you care about privacy, security, or simply want to prevent your ISP from logging every domain you visit, understanding and enabling DNS over TLS is one of the highest-value changes you can make to your network configuration.
What DNS over TLS Actually Does
Standard DNS operates over UDP port 53. The protocol was designed in the early 1980s when the internet was a trusted academic network, and encryption was not part of the plan. When your device queries a resolver, the request and the response are both unencrypted. Anyone running a packet capture on your network segment, your ISP, or a malicious actor on public Wi-Fi can see exactly which domains you are querying, when, and how often.
DNS over TLS, defined in RFC 7858 (published 2016), adds a TLS handshake before any DNS data is exchanged. The resolver and the client negotiate an encrypted session over TCP port 853, and all queries and responses flow through that encrypted channel. The DNS protocol itself is unchanged — only the transport layer is different. From a privacy standpoint, an eavesdropper sees only that you opened a TLS connection to an IP address on port 853. The actual domain names you queried are hidden.
DNS over TLS vs DNS over HTTPS
You will frequently see DNS over TLS compared to DNS over HTTPS (DoH), which is defined in RFC 8484. The core difference is the transport port and protocol. DoH uses HTTPS on port 443, which means DNS traffic is indistinguishable from ordinary web traffic. DoT uses a dedicated port (853) that is purpose-built for encrypted DNS. Network administrators can allow or block DoT precisely because it uses a distinct port, whereas DoH is harder to filter. For home users and privacy-focused individuals, both are strong options. For enterprise environments where DNS visibility matters for security monitoring, DoT is often the preferred choice because it can be audited and controlled without breaking HTTPS inspection.
Why Plain DNS Is a Real Threat
The risks of unencrypted DNS are not theoretical. ISPs in many countries are legally permitted — or required — to log DNS queries and sell or share that data. On public Wi-Fi, attackers can perform DNS spoofing attacks, redirecting your queries to malicious IP addresses that serve phishing pages while your browser shows no warning. Even on a home network, if your router is compromised, an attacker can silently redirect all DNS traffic to a rogue resolver without your knowledge.
DNS over TLS addresses two of the three main DNS attack categories: eavesdropping and tampering in transit. It does not replace DNSSEC, which authenticates the data returned by the authoritative nameserver. The two technologies are complementary: DNSSEC verifies that the answer has not been tampered with at the source, while DoT ensures the query and answer cannot be read or modified in transit between your device and its recursive resolver.
Which Resolvers Support DNS over TLS
You need a recursive resolver that speaks DoT on port 853. The most widely used options are:
- Cloudflare — 1.1.1.1 and 1.0.0.1, hostname: one.one.one.one
- Google Public DNS — 8.8.8.8 and 8.8.4.4, hostname: dns.google
- Quad9 — 9.9.9.9, hostname: dns.quad9.net (blocks known malicious domains)
- NextDNS — custom per-account hostname, supports filtering and logging controls
The hostname is important for authentication. During the TLS handshake, your client checks that the server's certificate matches the expected hostname. Without this check, a rogue server could terminate the TLS connection and you would have no way of knowing. Always configure both the IP address and the authentication name (sometimes called the Server Name Indication, or SNI) when setting up DoT.
Enabling DNS over TLS on Android
Android 9 and later include a built-in Private DNS feature, which is DNS over TLS. The setting is straightforward and applies system-wide to all apps on the device.
- Open Settings and navigate to Network and Internet.
- Tap Private DNS (on some manufacturer skins this is under More connection settings or Advanced).
- Select Private DNS provider hostname.
- Enter the resolver hostname, for example one.one.one.one for Cloudflare or dns.google for Google.
- Tap Save. Android will verify the connection immediately.
If the hostname cannot be reached on port 853, Android falls back to the network's default DNS — it will not leave you disconnected, but it also silently stops encrypting queries. Check that port 853 is not blocked by your firewall if the setting does not activate.
Enabling DNS over TLS on Linux with systemd-resolved
Modern Linux distributions using systemd-resolved can enable DoT with a small configuration change.
Find or add the following lines under the [Resolve] section:
Save the file, then restart the service:
To verify the connection is encrypted, run:
Look for DNS over TLS: yes in the output. If you see opportunistic instead of yes, change DNSOverTLS=opportunistic to DNSOverTLS=yes to enforce encryption and reject unencrypted fallback.
Enabling DNS over TLS on Windows
Windows 11 and Windows 10 (build 19628 and later) support DoT natively, but the configuration is not exposed in the GUI for all scenarios. The most reliable method uses PowerShell with the netsh command or the newer DNS client settings in Windows 11.
On Windows 11: Go to Settings > Network and Internet > Wi-Fi (or Ethernet) > Hardware properties > DNS server assignment > Edit. Set the DNS server to 1.1.1.1, select DNS over HTTPS or check if your build shows a DoT option. Windows 11 currently exposes DoH more prominently than DoT in the GUI.
For DoT enforcement via PowerShell on Windows 11:
Note that Windows currently uses the DoH endpoint even when you intend DoT. For strict DoT on Windows, third-party clients such as Stubby provide more granular control.
Enabling DNS over TLS on Your Router
Configuring DoT at the router level is the most powerful approach because every device on your network benefits automatically — phones, smart TVs, IoT devices, and laptops all get encrypted DNS without individual configuration.
Asus Routers (AsusWRT)
Access your router admin panel at asusrouter.com or 192.168.1.1. Navigate to WAN > Internet Connection. Scroll to the DNS Privacy Protocol section, select DNS-over-TLS (DoT), and enter your resolver IP and TLS hostname. Asus routers running firmware 3.0.0.4.386 and later support this natively.
TP-Link Routers (running OpenWrt or stock firmware)
Access the admin panel at tplinkwifi.net or 192.168.0.1. On stock TP-Link firmware, DoT support varies by model. Newer Deco and Archer models with updated firmware include an Advanced > Network > DNS section where you can enable Secure DNS. For full control, flashing OpenWrt gives you access to the stubby or unbound packages which implement DoT properly.
Netgear Routers
Log in at routerlogin.net or 192.168.1.1. On newer Netgear Nighthawk models with the latest firmware, go to Advanced > Setup > Internet Setup and look for DNS settings. Netgear's Armor-enabled routers handle DNS filtering at the cloud level, which is a different feature. For DoT specifically, the most reliable path on Netgear hardware is again OpenWrt or installing a Pi-hole with Stubby on your local network.
Using Stubby on a Local DNS Proxy
If your router firmware does not support DoT natively, running Stubby on a Raspberry Pi or any always-on Linux machine gives you DoT for the entire network. Install Stubby, point it to your chosen resolver on port 853, and set your router's DHCP DNS option to the Pi's local IP. All devices get DoT transparently.
Edit /etc/stubby/stubby.yml to configure your upstream resolvers with their TLS authentication names, then configure your DHCP server to hand out the Stubby host's IP as the DNS server for your LAN.
How to Verify DNS over TLS Is Working
Trusting that DoT is active without verifying is not good practice. Use these methods to confirm encrypted DNS is actually in use.
Packet capture test: Run Wireshark or tcpdump and filter for DNS traffic on port 53. If DoT is working correctly, you should see no traffic on port 53 during normal browsing. You will see TLS traffic on port 853 instead.
If this command shows active DNS queries while you browse, your DoT configuration is not working and traffic is leaking in plain text.
Cloudflare's test page: Visit 1.1.1.1/help in a browser. Cloudflare reports whether your query arrived via DoT, DoH, or plain DNS.
You can also use our DNS Lookup tool to confirm that your domains are resolving as expected after switching resolvers, which can catch cases where a misconfigured DoT setup causes specific records to fail.
Common Problems and How to Fix Them
Port 853 is blocked: Some ISPs or corporate firewalls block outbound TCP port 853. If DoT cannot connect, verify with:
If the connection times out, your network is blocking port 853. Switch to DNS over HTTPS (port 443) as an alternative, or contact your ISP.
Certificate validation failure: If your DoT client cannot validate the resolver's TLS certificate, it should refuse to connect. Make sure your system's root CA certificates are up to date. On Debian/Ubuntu: sudo apt install ca-certificates.
Slow DNS resolution: DoT adds a small latency overhead for the TLS handshake on the first connection. Modern implementations use TLS session resumption and connection keepalives to minimize this. If DNS feels slow after enabling DoT, check whether your client is reusing connections or establishing a new TLS handshake for every single query, which would indicate a misconfiguration in the client software.
Preventing DNS Leaks Going Forward
DNS over TLS solves transport-layer privacy, but other leak vectors exist. If you use a VPN, make sure the VPN client's DNS handling does not bypass DoT — some VPN clients override system DNS settings and send queries in plain text through the VPN tunnel. Test for DNS leaks periodically, especially after OS updates or firmware changes that might reset network configuration. Set up monitoring alerts if you are managing a network, since configuration drift can silently revert DoT settings after a router reboot or firmware upgrade.
For the highest level of protection, combine DNS over TLS with DNSSEC validation at the resolver level (Cloudflare, Google, and Quad9 all validate DNSSEC), and consider using a resolver with a published privacy policy and a no-logs commitment. DNS over TLS is not magic — the resolver you connect to still sees your queries. Choosing a trustworthy resolver is just as important as encrypting the transport.
Summary
DNS over TLS is a mature, standardized protocol that eliminates one of the most persistent privacy gaps in everyday internet use. Enabling it takes under five minutes on Android, requires a small configuration file edit on Linux, and is available natively on modern routers from Asus, TP-Link, and others. The combination of an encrypted transport channel, a reputable resolver, and periodic leak testing gives you a meaningfully more private and tamper-resistant DNS setup compared to the default plain-text UDP queries that most devices still use today.