Why Now Daily.

Published

Encrypted DNS in Browsers: Resolver Privacy and Limits

Encrypted DNS protects domain-name lookups between a browser and its chosen resolver, but the resolver can still see queries and other parts of a connection can reveal destinations. Browser fallback rules and resolver data practices therefore matter.

Timeline

  1. Before a site loads: The browser resolves a domain name through its configured DNS path, which may use encrypted HTTPS transport.
  2. During resolution: The chosen recursive resolver receives the query and returns address records or another DNS response.
  3. After resolution: The browser makes a separate connection to the destination; encrypted DNS alone does not encrypt that traffic or hide every destination signal.

DNS translates a domain name such as example.com into network information a device can use. Traditional DNS queries have often traveled without transport encryption between a device and a recursive resolver. DNS over HTTPS, usually shortened to DoH, carries the query and response inside an authenticated HTTPS connection. RFC 8484 says this protects the confidentiality and integrity of that link and makes passive observation or casual alteration of the lookup harder. [1][2]

The protection has a precise boundary. DoH encrypts the path from the browser or other client to the selected DoH resolver; it does not make the query invisible to that resolver. IETF guidance notes that a privacy-service operator can still have visibility into query data and transport identifiers, subject to its technical design, logging and retention policies. Choosing a resolver therefore changes whom the user trusts with DNS data rather than eliminating trust. [1][3]

Encrypted DNS also is not a VPN and does not encrypt an entire browsing session. The destination still needs a network connection, and the website sees the connection it receives. Network metadata, IP addresses and other protocol signals may reveal information even when the DNS lookup is protected. HTTPS on the website connection protects web content in transit; DoH protects the DNS exchange. The two solve related but separate problems. [1][2][3]

Browser settings affect failure behavior. Firefox documents Default, Increased and Max Protection modes: the default can fall back or disable DoH in circumstances such as certain VPN, parental-control or enterprise configurations, while Max Protection warns when secure resolution is unavailable. Chrome says its automatic mode may fall back to an unencrypted lookup when it has trouble, whereas selecting a custom provider prevents that automatic fallback. A switch labeled secure DNS therefore does not always guarantee identical behavior. [4][5]

Resolver choice can affect filtering, local names and reliability. A network-provided resolver may know private hostnames used only on that network, while an external resolver may not. Family filters, enterprise security controls and captive portals can also depend on the local DNS path. Firefox explicitly accounts for parental controls, enterprise policy and some network signals. If secure DNS breaks a sign-in page or an internal address, inspect the browser mode and network policy before assuming the website is down. [4][5]

For privacy, compare a provider’s policy on query logging, retention, sharing and jurisdiction, not just its use of encryption. RFC 8932 recommends that DNS privacy operators disclose data handling and minimize what they retain. A provider may offer strong transport security while keeping operational logs, and another may promise shorter retention. These are policy differences that the DoH protocol itself cannot settle. [3]

A practical setup is to use the browser or operating system’s current secure-DNS control, choose a resolver whose policy you understand and select a strict mode only if you can tolerate resolution failures instead of fallback. Managed devices should follow the organization’s instructions. If a site will not load, compare another network, check the selected resolver and review the browser’s official documentation before turning protection off globally. Encryption improves the lookup path, but it should be one layer alongside HTTPS, updated software and sensible account security. [3][4][5]

Sources

  1. RFC Editor — RFC 8484: DNS Queries over HTTPS
  2. RFC Editor — RFC 7626: DNS Privacy Considerations
  3. RFC Editor — RFC 8932: Recommendations for DNS Privacy Service Operators
  4. Mozilla Support — Configure DNS over HTTPS Protection Levels in Firefox
  5. Google Chrome Help — Manage Chrome Safety and Security

Related stories