Lewati ke konten utama
Life Security

Cari di situs

Temukan halaman dan bagian.

DNS overview

Terakhir diperbarui:

Every time you open a website or an app, your device first asks a server where that service lives. That question is a DNS lookup, and most people never see it. It matters because the lookup names the site you’re about to visit, and on many networks it travels unencrypted, so whoever relays or answers it can read it.

A page can be fully protected by HTTPS and the list of sites you visit still leaks through DNS. The IETF’s analysis of DNS privacy, RFC 9076, puts it with an example: the website of Alcoholics Anonymous is public, but the fact that you visited it shouldn’t be.

After reading this you’ll know who can see your lookups, what encrypted DNS fixes and what it leaves exposed, where DNSSEC fits, and which settings are worth ten minutes of your time. We don’t cover picking a specific DNS provider, DNS-based ad blocking, or running your own resolver. Each of those needs its own page.

What DNS is, in plain terms

Computers find each other by numbers called IP addresses. People use names like example.org. DNS is the lookup service that turns one into the other. Software on your device, called a stub resolver, hands each question to a recursive resolver, a server that does the legwork of finding the answer (RFC 9076).

Here’s a concrete case. You join the Wi-Fi at an airport and open your clinic’s patient portal. Your phone didn’t choose a resolver. The network told it which one to use when you connected, which is the normal arrangement, and RFC 9076 notes that the vast majority of people never change it. So the airport’s resolver, or its internet provider’s, now holds a record that your phone asked for the clinic’s address at 9:14 in the morning.

How a lookup works

Take a lookup for www.example.com when nothing is saved anywhere along the way:

  1. Your stub resolver asks the recursive resolver.
  2. The recursive resolver asks a root name server. The root doesn’t know the answer, but it points to the servers responsible for .com.
  3. The resolver asks a .com server, which points to the servers that handle example.com.
  4. The resolver asks those servers. They’re called authoritative name servers because they hold the real records, and they return the IP address.
  5. The recursive resolver passes the answer to your device and keeps a copy for a limited time.

That copy is why most lookups skip steps 2 to 4. It’s also why the different servers see different amounts. A stub resolver typically doesn’t cache, so the recursive resolver sees nearly all of your lookups, while the authoritative servers only see the ones the resolver couldn’t answer from memory (RFC 9076). Unless the resolver uses a technique called QNAME minimization, each server up the chain receives your full original question, not just the part it needs.

One page also means many lookups. A single web page can trigger lookups for dozens of domain names, because of embedded images, scripts and ads, and browsers sometimes look up names ahead of time in case you click (RFC 9076). The list your resolver builds is longer and more revealing than the list of sites you meant to visit.

Who can see your lookups

It depends on where your resolver sits and whether the traffic is encrypted.

Who What they can see When
Anyone between you and your resolver, such as a Wi-Fi operator or your internet provider Every domain you look up, and they can alter the answers Lookups are unencrypted
The operator of your resolver (your provider, your employer or a public DNS service) Every lookup your devices send it, tied to your IP address Always, encrypted or not
Authoritative name servers Only lookups the resolver couldn’t answer from cache, normally with the resolver’s address rather than yours Your address can leak if the resolver forwards part of it using a feature called EDNS client subnet

The table rows come from RFC 9076, which also covers the “alter the answers” part: an attacker who controls the network can substitute their own replies to any unencrypted lookup.

What your resolver’s operator does with the data is a policy question, and policies vary. RFC 9076 says privacy policies for network-provided resolvers may or may not be available, while large public services such as Google Public DNS, Cloudflare and Quad9 publish theirs. Some resolvers also block certain domains on purpose, usually known malware sites. That’s useful when it’s what you want and confusing when it isn’t.

What encrypted DNS fixes, and what it leaves exposed

Three standards wrap a lookup in encryption between your device and your resolver.

Name Port Standard Notes
DNS over TLS (DoT) 853 RFC 7858, 2016 Easy for a network to recognise by its port. Android’s Private DNS setting used it when introduced in 2018.
DNS over HTTPS (DoH) 443 RFC 8484, 2018 Travels on the same port as ordinary web traffic, so it’s harder to single out or block. Firefox uses it.
DNS over QUIC (DoQ) 853 (UDP) RFC 9250, 2022 Its specification says the privacy properties resemble DoT.

All three do the same basic job. People between you and the resolver can no longer read your lookups or tamper with them. At the airport, the Wi-Fi operator can see that your phone talks to a resolver, but not that it asked for the clinic.

The limits matter as much as the benefit:

  • The resolver still sees everything. RFC 9076 is blunt that encrypted transports don’t reduce what the resolver learns, and can even give it more to correlate. You haven’t removed a watcher. You’ve chosen which one to trust.
  • Traffic analysis still works to a degree. The sizes and timing of encrypted queries can be matched against what a resolver sends upstream. Padding reduces this, but RFC 7858 says simple padding alone might not be enough.
  • Weak configurations can be downgraded. If your device learns about an encrypted resolver from the network and doesn’t verify it, an attacker on that network can interfere (RFC 7858). Android’s “Private DNS provider hostname” mode is the stricter kind: it sends queries to the server you named over a secure channel, or marks the network as having no internet access if it can’t reach that server (Google Security Blog, 2018).
  • A small resolver can make you easier to track. RFC 9076 observes that one resolver with few users, even over encryption, can help someone follow you from network to network.
  • It can switch off filters. Mozilla’s documentation says DoH bypasses local resolvers and with them any malware blocking or parental controls, which is why Firefox checks for these and backs off when it finds them.
  • Networks can block it, and devices can fall back. RFC 7858 warns that port 853 may be blocked by some firewalls. Firefox’s default rollout uses a fallback mode, so if DoH lookups fail it quietly uses the system’s ordinary DNS.

The site name leaks a second time

Encrypting the lookup doesn’t finish the job. When your browser opens an HTTPS connection, its first message includes the name of the site it wants, in plain text. That field is called the Server Name Indication, or SNI, and anyone watching the connection can read it (Cloudflare, 2023).

Encrypted Client Hello, or ECH, closes that gap. The site name goes inside an encrypted part of the message, and the visible part carries a shared name instead. On Cloudflare, every ECH-enabled site shows the same outer name, cloudflare-ech.com. Mozilla’s FAQ says Firefox has enabled ECH by default since version 119, and describes the privacy gain as strongest when many sites share one server. ECH only works when the site supports it, and Mozilla says many don’t yet.

ECH is tied to DNS in one way and leaves one gap. In Firefox, ECH gets its encryption keys from a DNS record, and Mozilla says it has the most privacy benefit alongside DoH. The gap is the server’s IP address, which your provider still sees. If a site has a server to itself, that address alone can give it away.

What DNSSEC adds

DNSSEC, short for DNS Security Extensions, lets a domain’s owner sign its DNS records. A resolver that checks the signatures can tell whether an answer was forged or altered on its way to you. RFC 7858 describes this as response integrity. The chain of signatures starts from a root key that validating resolvers keep as their trust anchor.

It does not encrypt anything. RFC 9076 says DNSSEC explicitly excludes confidentiality from its goals. It only protects domains whose owners have signed them and resolvers that check, and it says nothing about whether the site at the end is honest. A scam site on a look-alike domain can be perfectly signed. With DoH, your device either validates DNSSEC itself or trusts the DoH server’s report (RFC 8484).

As of October 2026 there’s a live example. ICANN says a new root key, KSK-2024, began signing the DNS root zone on 11 October 2026 at 14:00 UTC, and that it had seen no signs of widespread disruption. Its instructions are addressed to people who run validating resolvers, who need to confirm the new key is in their configuration. Unless you run your own resolver, there’s nothing for you to do.

Common myths

“Encrypted DNS hides my browsing.” It hides your lookups from the network between you and the resolver. The resolver still sees them, the connection still reveals an IP address, and without ECH it still reveals the site name.

“DNSSEC and encrypted DNS are the same thing.” They solve different problems. RFC 7858 and RFC 8484 both say the two are independent and compatible, and that using one doesn’t replace the other.

“DoH is the private one and DoT is the weak one.” The specifications don’t support a winner. RFC 9076 notes that DoH carries more HTTP features that can act as identifiers, and says privacy-focused users may prefer implementations that are clear about what they send. RFC 8484 says DoH isn’t known to add concerns beyond those of HTTPS itself. In practice the gap is small next to the choice of resolver.

What to do

Whether any of this is worth your time depends on who you’re worried about: a hostile Wi-Fi operator, your internet provider, or a network that blocks sites. If you haven’t mapped that yet, start with threat modeling. The steps below are ordered by how much they help for the least effort. This page is general information, not professional security advice for a specific situation.

  1. Turn on encrypted DNS for the whole device, not for one app. Phones that join public Wi-Fi gain the most. On Android, look for Private DNS, usually under Settings, then Network & internet, though manufacturers move it. Choose “Private DNS provider hostname” and enter your provider’s hostname. Apple’s iOS and macOS support system-wide DoT or DoH, but as of October 2026 we only confirmed that an app can set it up and that you must approve it (Apple Developer). The cost: some hotel and airport login pages depend on the network’s own DNS, and Android will show “no internet access” if it can’t reach your named server. Switch it off for that sign-in, then back on.
  2. Pick the resolver on purpose. Read its privacy policy for what it logs, for how long, and who gets it. A policy is a promise, not a technical guarantee, though some services back theirs with contracts, as Mozilla does with its DoH partners. This page doesn’t rank providers.
  3. Keep your browser updated so ECH can work. There’s nothing to configure in Firefox. Mozilla’s FAQ points to Cloudflare’s browser check to see whether it’s working for you.
  4. If you use parental controls or a filtering resolver, make that resolver your encrypted one. Browser DoH can bypass local filtering, and Mozilla says DNS-based ad blockers should use an encrypted connection upstream, or visited sites leak indirectly.
  5. On a work or school device, leave the DNS settings alone. Managed networks can switch off DoH for policy reasons, and Firefox backs off on managed devices. Your employer’s resolver sees your lookups either way.

As of October 2026, Mozilla says Firefox desktop users in the United States and Canada get DoH by default, a rollout to Russia and Ukraine began in 2022, and more countries are planned. The default resolver is a trusted partner of Mozilla’s. Its settings let you opt out or choose a different provider, in the DNS over HTTPS section of Firefox’s settings.

Sources

Pertanyaan yang sering diajukan