Who Answers Your DNS Queries?

Before a browser opens a connection it has to ask where to send it, and for thirty years that question was answered by a server the network operator picked. That single fact made DNS the cheapest control point anyone has ever been handed. There is no agent to install, no certificate to distribute, no traffic to decrypt and no per-device configuration, because the resolver address arrives with the DHCP lease and every device on the network takes what it is given.

The arrangement rested on an assumption nobody wrote down, which is that applications would use the resolver they were given. Encrypted DNS ended that. A program speaking DNS over HTTPS to an endpoint it chose is making a request indistinguishable from any other HTTPS session, to a host it picked, on a port you cannot close without closing the web. There is nothing left to intercept, because the thing you used to intercept was plaintext on its own port and that is not what is being sent.

So here is the sentence the rest of this is about. Running your own resolver is still worth doing, and the honest reason is measurement and failure isolation rather than blocking, because anything shipping its own encrypted endpoint has already opted out of your network and no amount of local policy brings it back. The control point did not weaken. It moved up the stack into the application, where you do not have a seat.

In February 2020 the default changed. Mozilla switched Firefox to DNS over HTTPS by default for users in the United States, resolving through its Trusted Recursive Resolver program with Cloudflare as the provider. The privacy case was sound, because plaintext DNS on a shared network is readable by everyone on it. The consequence is that a browser on a managed network started asking a resolver that network had never heard of, and the network's own answer stopped being consulted at all.

Chrome took a different route to the same place. Chrome shipped secure DNS from version 83 in May 2020 with a short list of preconfigured providers: Google Public DNS, Cloudflare, Quad9, NextDNS and CleanBrowsing. Five choices is not the open internet, and that is the part worth noticing. Encrypting resolution has concentrated it. Queries that used to spread across every operator's resolver now land at a handful of very large ones, which is a different privacy posture rather than an unambiguously better one.

Then the name itself began to disappear. Encrypted Client Hello encrypts the whole TLS ClientHello, including the server name that has been the fallback signal for any network wanting to know where a connection is headed. Chrome turned it on by default in version 117 in September 2023 and Firefox in 119 that October, and it is still a draft standard as I write this. It works by publishing keys in HTTPS and SVCB records, which is the irony worth sitting with: the mechanism that hides the destination is delivered over DNS.

I have run a filtering resolver at home for years and I would not remove it, so I want to be precise about what it is actually buying, because the popular reason is the weakest one. Blocking advertising and telemetry at the resolver works, unevenly, for the devices that still ask you. It stops working for anything carrying its own encrypted endpoint, and the number of things in that category grows every year without consulting anybody.

The reason that survives is measurement. A query log is the only inventory of a network that asks nothing of the devices on it. Plug in an appliance and within an hour you know which company it phones, how often, and what it does when the answer is slow. That is knowledge rather than a control, and nearly every argument I have had about a device on a network was settled by somebody producing the list of names it asked for.

The second reason is failure isolation, and nobody advertises it. A resolver you run is a dependency you can restart. When resolution breaks at three in the morning, the gap between a service you operate and a service you subscribe to is the gap between a diagnosis and a wait. Local resolution also means a building keeps resolving its own names when the wide area link drops, which is an availability property and not a privacy one at all.

It is a filtering forwarder, and that is a category. Pi-hole resolves nothing itself. Its DNS component, pihole-FTL, is based on dnsmasq, and what it does is take a query, check the name against blocklists and per-client group policy, then either synthesize a refusal or hand it to whatever upstream you configured. Caching, local hostnames and DHCP come along with it. It is not an authoritative server and never tried to be, and most arguments about it come from missing that.

Version 6 changed that on the eighteenth of February. The v6 release folded the web interface and a REST API into the pihole-FTL binary and dropped the lighttpd and PHP dependencies outright, consolidated the settings into one commented pihole.toml, and added subscribed allowlists alongside blocklists. Taking a web server and a language runtime off a box whose entire job is answering one protocol is the right direction, and it shrinks the attack surface of the most privileged small service on the network.

Then there is what it will not do. No authoritative zones, so no delegated subdomain you can point other systems at. No split horizon, so no serving one answer inside and another outside. No zone signing. Policy is per client rather than per view, which covers everything a house wants and nothing an office with an internal domain needs. None of these are defects. They are the boundary of what a forwarder is, and the boundary is where the decision gets made.

Authoritative zones come with everything that implies. BIND is the reference implementation and it will serve zones you own: an internal domain with real delegation, records other systems are pointed at, secondaries taking transfers from a primary. That is the thing a forwarder structurally cannot do. The cost is that you are operating a DNS server now, with zone files, serial numbers that have to increment, and a configuration language that does not forgive a missing semicolon in a way you will enjoy discovering at midnight.

Split horizon is the usual real reason. Views let the same name resolve differently depending on who asked. The ISC documentation puts it plainly: setting up different views of the DNS space to internal and external resolvers is what a split DNS setup is. If an internal service has to answer on a private address inside the building and a public one outside it, this is the mechanism, and it is the most common reason an organization outgrows a forwarder.

RPZ is how blocking is done at scale. Response Policy Zones express firewall rules as records inside a DNS zone. Each rule is a trigger - the query name, the client address, the answer data, the authoritative nameserver - paired with an action: NXDOMAIN, NODATA, DROP, TCP-only, a CNAME override, or PASSTHRU to exempt something from further policy. Because the policy is itself a zone, it propagates by ordinary AXFR and IXFR transfer, so ten resolvers stay consistent without configuration management touching any of them.

Signing and validation live in the same program. BIND signs authoritative zones, through dnssec-policy for automatic signing and key maintenance, through inline signing, or by hand with dnssec-signzone. A recursive BIND with dnssec-validation auto is a validating resolver. If anything in your estate needs a signed internal zone, that is not a capability you bolt onto a forwarder later. It is a reason to have chosen differently at the beginning, and it is worth knowing before you install anything.

Unbound is described by its authors as a validating, recursive, caching DNS resolver, and every one of those words is load-bearing. Recursive means it does the walk itself, from the root to the top level domain servers to the authoritative server for the name, rather than handing the question to somebody else and taking their word for the answer. Validating means it checks DNSSEC signatures instead of trusting. It is not authoritative and does not pretend to be.

Forwarding to a public resolver hands your entire query stream to one aggregator: every name, every client, in order, correlated over time, arriving from a single address. Recursing yourself spreads the same stream across the root servers, the top level domain operators and every authoritative server you touch, each seeing the fraction that concerns it, alongside your address. Neither of those is private. They are different exposures, and the second is worse on number of counterparties and better on concentration.

It costs something too, and the enthusiasts undersell this. A cold recursive cache is slower than a warm public one, noticeably on the first visit to a name, and a large provider has caches a household will never approach. You now depend on reaching hundreds of authoritative servers rather than one endpoint, which is more surface even though each piece of it is more robust. Query name minimization narrows the exposure and does not remove it. Choose the exposure you prefer, and stop calling it privacy.

If you need internal zones, split horizon or a signed internal domain, Pi-hole alone is the wrong tool and no amount of configuration makes it the right one. That is not a close call, and the failure mode is finding out eighteen months later when something needs a delegation and the answer is a rebuild. If what you need is filtering, per-client policy, local hostnames and a query log, BIND is a great deal of machinery for a job a forwarder already does well, and the difference gets spent on zone maintenance rather than on anything you wanted.

Most homelabs need the forwarder and believe they need the server, and the belief is usually about having built the serious thing rather than about a requirement. The honest test is a single question: is there a name your organization owns that has to resolve differently inside than outside? If there is, you have crossed the line and should cross it deliberately. If there is not, running a full authoritative server to block advertising is buying a lathe to open envelopes.

Pairing the two is the answer for the middle, which is where most people actually are. Pi-hole in front for policy and visibility, Unbound behind it for resolution, no authoritative zones at all: two small programs on one machine, each doing the one thing it is for. That arrangement has exactly one serious problem, and it is the problem nobody plans for.

A single resolver is a whole-site outage. When the resolver stops, nothing resolves, and nothing resolving looks to every user like everything breaking at once. It is not a partial failure and it does not degrade gracefully. The phone, the television, the laptop and the door controller all stop at the same instant. Nothing else on a house or small office network has that blast radius, and it is usually running on the cheapest computer in the building, on a memory card.

It is probably your DHCP server as well. Pi-hole will serve DHCP, and on a small network it usually does, which quietly doubles what that machine is carrying. Lose it and you lose resolution immediately and addressing over the following hours as leases expire, which is a slower and far more confusing failure than the first one. If one box has to hold both, at least know the recovery has two halves and that the second half runs on a timer you did not set.

The upgrade is an outage you scheduled. A rewrite of the size v6 represents is exactly the change that takes a resolver down for a few minutes, and a few minutes without DNS is a call from everybody in the building. That is the practical argument for a second resolver and it has nothing to do with hardware failing. With two, an upgrade is a maintenance window on one of them. With one, an upgrade is an event, so it gets deferred, and a deferred upgrade on the most privileged service is its own problem.

The list you hand out matters more than the resolver. Client failover is not what people assume it is. A stub resolver given two addresses will try the second one eventually, after a timeout long enough that the user has already given up, and some clients favor whichever answered first for a while afterward. So the resolver list served by DHCP - what is in it, in what order, and how fast a client abandons the first entry - decides your real availability more than the reliability of either machine.

I should narrow the pessimism, because this reads easily as an argument that local DNS control is finished and I do not believe that. On a managed fleet with managed browsers, DNS policy is still enforceable and still the cheapest enforcement on offer, and encrypted endpoints can be turned off by policy on devices you administer. What ended is the assumption that controlling the resolver controls the network, and that was only ever true because nothing had yet tried to leave.

What survives is smaller and more useful than what was lost. The resolver is not a gate any more, and it is still the only place a network describes itself in its own words: a plain list of every name anything on it wanted, in order, with a timestamp against each. Half the devices are talking past it now and will keep doing so. The half that still asks is telling you the truth, and there is no other log in the building anywhere near that cheap.