Versus your resolver's dashboard
Seven questions asked of both, and a fair account of what the resolver does better.
AdGuard HomePi-hole is not the competition. It is the thing answering DNS, and every number on every screen here came out of it. What it is not is an analytics product, and it does not claim to be.
Seven questions, asked of both#
Framed as questions rather than features, because that is how the difference actually shows up. Both can count blocked queries. The difference is what happens when you want to know something about them. The left-hand column is AdGuard HomePi-hole, following the switch in the header.
Which device is that, and what is it doing?
See the device listAdGuard HomePi-hole
A client list of IP addresses with whatever names you typed in yourself, and per-client counts that only cover the buffer.Genuinely good: a per-client page with reverse-resolved names and its own history. What it does not do is characterise a device — no vendor, no rhythm, no sense of normal.
elele. DNS
Named devices with vendor and hardware from the MAC, a rhythm chart by hour of the week, and every domain each one resolved.
Who is actually on the other end?
See the organisationsAdGuard HomePi-hole
Hostnames. sb.scorecardresearch.com is on the list; knowing that it is Comscore is left to you.Hostnames, and a Top Domains list. Same gap: sb.scorecardresearch.com is a string, and mapping it to Comscore is left to you.
elele. DNS
Hostnames attributed to organisations with categories, so the ranking reads as companies rather than as strings.
Where does my traffic physically go?
Open the mapAdGuard HomePi-hole
Not answered. The resolved addresses are in the API response and nothing displays them.Not answerable. FTL records the kind of reply it sent but not the addresses in it, so the data does not exist to display — and this product cannot show it either.
elele. DNS
Every answer geolocated to a city and drawn on a map, live, one arc per query as it lands. On Pi-hole this screen is hidden rather than shown empty.
Is my blocking annoying anybody?
See what it costAdGuard HomePi-hole
Not answered. A blocked count treats one refusal and four hundred retries as the same event.Not answered. The same flat count: one refusal and four hundred retries are one number.
elele. DNS
Refusals grouped into episodes, so a name refused once and dropped is separated from one a client kept asking for.
Why did that site break, just now?
Open a moment from any rowAdGuard HomePi-hole
Scroll the log and hope the relevant seconds have not been overwritten yet.Better odds, because FTL keeps the rows: filter the query log to the client and the minute, and read it by eye.
elele. DNS
A moment view: every lookup either side of an instant, on one timeline, with the retries marked.
Is a device routing around the filtering?
See the bypass detectorAdGuard HomePi-hole
Not answered. A device using DoH simply stops appearing, which looks identical to one that went quiet.Not answered. Same blind spot: a device on DoH stops appearing, and silence reads identically to absence.
elele. DNS
Lookups of known DoH resolvers and the Firefox canary surfaced as a signal, stated as intent rather than proof.
Which upstream is having a bad week?
See resolver healthAdGuard HomePi-hole
Not answered. Resolution time is recorded per query and never aggregated.Partly. There is an upstream breakdown by count, but reply times are per query and never aggregated into a distribution.
elele. DNS
Latency distribution per upstream with p50, p95 and the spread between them, cache hits excluded.
The constraint underneath all seven#
circular buffer, overwritten within the dayFTL's own database: real history, but not the enriched detail these pages read
per-query detail, then hourly rollups that never expire
Six of those seven are downstream of one thing: how much history exists to ask the question of. Why history is the whole argument goes into it properly.
What the resolver does better#
It answers DNS, which is the hard part and the part that has to be right at three in the morning. It has the filtering engine, the rule syntax, the handling, DHCP, encryption and a decade of edge cases nobody sensible wants to reimplement. It is also the only one of the two that keeps working when the other is switched off.
Nothing here replaces any of that. This reads its log and gives the data somewhere to be looked at.
AdGuard Home specifically also has the better settings surface of the two, which is why the control section is nine screens deep against it and one screen deep against Pi-hole.
Pi-hole specifically keeps far more history than AdGuard Home does — FTL’s database defaults to a year, where AdGuard’s buffer is gone inside a day. The retention argument below is therefore weaker here, and it is worth being straight about that: what this adds on Pi-hole is enrichment, attribution and the questions in the table above, not merely the fact of keeping the rows.
The other resolver#
Pi-hole is supported too: set DNS_PROVIDER=pihole, point it at a v6 instance, and flip the switch in this wiki’s header to read every page as it applies there. Everything downstream of ingest is schema-shaped rather than vendor-shaped, so the questions above are answered from the same code either way.
AdGuard Home is the other supported resolver, and the default: set DNS_PROVIDER=adguard, or just flip the switch in this wiki’s header to read every page as it applies there. Everything downstream of ingest is schema-shaped rather than vendor-shaped, so the questions above are answered from the same code either way.
The differences are confined to where the resolvers genuinely differ: the destinations map needs the addresses inside each answer, which FTL does not expose, and hardware vendor labels need MACs, which are behind Pi-hole endpoints this does not read yet. Everything else — devices, companies, friction, moments, bypass detection, upstream latency — works the same on both. See the FAQ.