Encryption has become standard across much of the web, but DNS can remain an exposed part of the connection.
Before a browser, package manager, or command-line tool reaches a service, the system usually translates a domain name into an IP address. If those lookups travel in plaintext, a network observer can learn which domains a machine is requesting even when the application itself uses HTTPS.
For Linux users, this matters increasingly as distributions, browsers, VPN clients, and system resolvers add their own approaches to encrypted DNS.
Name resolution can now involve NetworkManager, systemd-resolved, a local resolver, a VPN connection, or an application with its own privacy settings. Understanding which path a query actually takes is becoming an important part of network administration.
Plain DNS still exposes useful metadata
Traditional DNS commonly uses port 53 without transport encryption. Someone with visibility on the local network, an ISP, or another intermediary may therefore observe requested domain names.
That does not reveal the encrypted contents of an HTTPS session, but the metadata can still expose software repositories, internal services, cloud platforms, or websites being accessed.
DNSSEC addresses a different problem. It helps validate DNS data and detect forged responses. It does not make the DNS request or response private.
Linux has more than one resolver path
Checking /etc/resolv.conf is useful, but it may not tell the whole story. On many distributions, the file is generated or points to a local stub resolver. NetworkManager can receive DNS settings from DHCP, systemd-resolved can route queries by interface, and applications may bypass the system resolver.
Browsers that enable DNS over HTTPS can send encrypted queries while other programs continue using the operating system’s resolver.
A desktop can therefore have private browser lookups and plaintext DNS from package managers or background services at the same time.
As encrypted DNS becomes available at more layers of the system, administrators need to know which component has responsibility for each query.
DoT, DoH, and VPN DNS are different
A VPN can send DNS traffic through its encrypted tunnel to a resolver chosen by the VPN service. Mixed-device environments need separate checks on each endpoint.
If a Mac is used to administer Linux systems, users can set up Private Internet Access on macOS easily and use the service’s DNS leak protection on that Mac. That does not configure DNS privacy on the Linux host.
DNS over TLS and DNS over HTTPS both encrypt traffic between the client and a recursive resolver. DoT normally uses a dedicated TLS connection, commonly on port 853. DoH carries DNS through HTTPS.
| Method | What it protects | What to verify |
| Plain DNS | No transport privacy | Which resolver receives queries |
| DoT | DNS traffic to the resolver | TLS policy and fallback |
| DoH | DNS traffic to the resolver | Application-specific settings |
| VPN-managed DNS | DNS inside the VPN path | Which endpoint and tunnel are active |
These approaches can coexist, which makes configuration more flexible but also creates more opportunities for unexpected fallback or application-specific behaviour.
Verify what the machine is actually using
Linux provides several ways to inspect the resolver path. On systems using systemd-resolved, resolvectl status shows DNS servers and per-link configuration. cat /etc/resolv.conf shows the resolver file applications may consult.
Packet capture provides another check. `sudo tcpdump -ni any port 53` can reveal conventional DNS packets leaving the machine while applications are active. Readers who need a refresher on shell-based diagnostics can start with our Linux command-line guide.
No visible port 53 traffic does not prove that every lookup follows the same encrypted path. DoH uses HTTPS, and individual applications can choose their own resolver. Testing should therefore cover the programs and interfaces that matter rather than relying on one system setting.
Encrypted DNS is becoming part of Linux itself
The growing importance of DNS privacy is visible in the operating system rather than only in browsers or third-party applications.
In September 2025, Red Hat’s guide to encrypted DNS on RHEL documented DNS over TLS as a Technology Preview in RHEL 9.6 and RHEL 10. The tested configuration included an exclusive mode intended to prevent fallback to unencrypted DNS.
Fedora has also worked on deeper system-wide DNS over TLS support. Developments such as these move DNS confidentiality closer to the network stack and allow administrators to apply resolver policies across more applications.
System-level support is particularly useful because browser-only encryption cannot protect DNS requests generated by every command-line utility, background service, or desktop application.
Privacy still depends on the resolver
Encryption protects DNS traffic while it travels to the resolver. The resolver itself still receives the queries, so its operator remains part of the trust decision.
Encrypted DNS also does not hide destination IP addresses from every observer, prevent application tracking, or replace HTTPS. DNSSEC remains useful for validating signed DNS data, while DoT and DoH address confidentiality in transit.
As Linux distributions add more encrypted DNS capabilities, DNS privacy is becoming something administrators can manage deliberately rather than accept as a browser-specific option.
The practical task is to understand the resolver path from application to network, check for unexpected fallback, and verify that the intended policy applies across the software actually running on the machine.
