PI-HOLE + AD-BLOCKING GLOSSARY
Nine terms that explain how DNS-level ad blocking works, why it sometimes fails, and what the terms actually mean when tuning a Pi-Hole setup. Each definition is linked to the pillar article that demonstrates it.
Pi-Hole
An open-source DNS sinkhole for Linux that blocks ads and trackers at the network level by refusing DNS resolution for domains on configured blocklists.
Pi-Hole runs on any Linux box — a Raspberry Pi, an old laptop, a VM, a NAS container. Every DNS query on the local network is sent to Pi-Hole instead of the ISP's default resolver. Queries for domains on the blocklists return 0.0.0.0 or :: instead of the real IP, which means the browser, phone, or smart TV never establishes a connection to the ad or tracker endpoint at all. The block happens at the DNS layer, before any HTTP request is made, which makes it faster and more effective than browser-extension blockers for many ad types.
Pi-Hole's strength is network-wide coverage: one box blocks ads on every device on the LAN, including phones and TVs that can't run browser extensions. Its main weaknesses are DoH-bypass in modern browsers (see The DoH Bypass) and the fact that DNS-level blocking cannot see inside encrypted HTTPS traffic to catch pop-unders, anti-adblock walls, or fingerprinting scripts embedded in otherwise-unblocked first-party domains.
DNS sinkhole
A DNS resolver configured to return a null or blackhole response for specific domains, preventing clients from ever connecting to the intended destination.
The idea long predates Pi-Hole. Corporate networks, security appliances, and every hosts-file-based ad blocker since the 1990s work on the same principle: if the DNS lookup for doubleclick.net returns 0.0.0.0, the client's browser has nowhere to send the HTTP request. The ad never loads. The tracker never fires. Other network-layer defenses like firewalls can do similar things at the IP level, but DNS is the cheapest and most maintainable place to enforce a blocklist.
Sinkholing fails against three categories of traffic: hardcoded-IP apps (which skip DNS entirely), first-party ad serving (where the ad is served from the same domain as the content), and encrypted DNS (DoH / DoT that bypasses the local resolver). Every high-scoring result on the PIHOLEKILLER gauntlet layers something else — a browser extension, a firewall rule, a VPN with its own filter — on top of the DNS sinkhole to close those gaps.
DNS over HTTPS (DoH)
A protocol for sending DNS queries over HTTPS to port 443, which encrypts the queries and makes them indistinguishable from web traffic to network-level filters.
DoH routes DNS queries through the same port and protocol as normal web browsing. Chrome, Firefox, Microsoft Edge, and Safari all support DoH natively; several enable it by default in specific regions. When a browser uses DoH, its DNS query goes to the configured DoH provider (typically Cloudflare 1.1.1.1 or Google 8.8.8.8) encrypted inside an HTTPS request — it does not go to the local network resolver at all. Pi-Hole never sees the query. The blocklist does not apply.
This is the single most important limitation of Pi-Hole in 2026. A Pi-Hole that scored 90+ on naive ad blocker tests five years ago now scores in the 60s or 70s because of DoH bypass. Closing the gap requires either router-level firewall rules that block known DoH endpoints, or the browser-extension layer (uBlock Origin, AdGuard) that blocks at the request level regardless of how DNS was resolved. See The DoH Bypass for the per-browser specifics.
DNS over TLS (DoT)
A protocol for encrypting DNS queries over TLS on port 853; visible to network operators as encrypted DNS traffic but not blockable at the content layer.
DoT is the older of the two encrypted DNS protocols and uses its own dedicated port (853). Unlike DoH, this makes DoT traffic identifiable — a firewall can block port 853 and force devices to fall back to plain DNS or DoH. DoT is commonly used by Android's Private DNS feature, some VPN clients, and some DNS resolvers on routers.
For Pi-Hole's purposes, DoT is easier to contain than DoH because you can block the port. DoH is harder to contain because blocking port 443 would break the entire internet. Many home routers (and most enterprise firewalls) selectively block DoT while leaving the web open; modern browsers, having seen this, moved to DoH specifically because it cannot be selectively blocked at the port level.
Blocklist
A list of domains flagged for blocking by a DNS filter; common formats include hosts-file syntax, AdBlock Plus syntax, and domain-only text files.
Blocklists are the content of an ad blocker. Without them a Pi-Hole is just a DNS resolver that blocks nothing. The most-used community lists in 2026 are Hagezi (tiered lists from "Light" to "Pro++" to "Multi Ultimate"), OISD (a curated mega-list), AdGuard DNS filter, and Steven Black's unified list. Each has tradeoffs between breadth (how many domains covered) and false positives (how often legitimate services get blocked).
List quality matters more than list count. A Pi-Hole with Hagezi Pro++ alone blocks more real ad-tech than a Pi-Hole with 20 random lists aggregated, because Hagezi is curated specifically to reduce false positives while covering the high-value ad networks. Adding more lists without quality control increases breakage without improving coverage.
Hosts file
A local operating-system file that maps hostnames to IP addresses, checked before DNS resolution; the original ad-blocking mechanism from the 1990s.
The hosts file (/etc/hosts on Unix-like systems, C:\Windows\System32\drivers\etc\hosts on Windows) predates DNS. Originally used to resolve a handful of hostnames on pre-internet local networks, it became the first ad-blocking tool: adding 0.0.0.0 doubleclick.net to hosts tells the OS to resolve that domain to a null address before any DNS query happens.
Modern DNS-based blockers like Pi-Hole are a network-level generalization of the same idea. A hosts-file blocklist applies only to the device it's on; a Pi-Hole applies to every device on the network. Blocklists are often distributed in hosts-file format for historical reasons, which Pi-Hole's gravity script parses into its own database.
Gravity database
The SQLite database Pi-Hole uses to store all configured blocklist domains and allow-list exceptions, updated via the gravity script.
Gravity is Pi-Hole's internal name for the blocklist aggregator. The gravity.sh script runs on a schedule (default: weekly), fetches every configured blocklist URL, parses each into domain entries, resolves conflicts with the allow-list, and writes the merged result to /etc/pihole/gravity.db. The DNS resolver (FTLDNS) reads from this database at query time. Running pihole -g manually forces an immediate update.
Understanding gravity matters when diagnosing why a specific domain is or isn't blocked. pihole -q <domain> shows which blocklist contains a queried domain; if a domain you expect to be blocked isn't, the answer is usually "no active blocklist contains it," "an allow-list entry overrides it," or "gravity hasn't updated since the list was added."
Anti-adblock
Client-side JavaScript or server-side detection that identifies when an ad blocker is active and responds with a paywall, nag banner, or obfuscated ad replacement.
Sites that lose revenue to ad blockers began deploying detection scripts around 2015. The simplest versions check whether known ad-serving scripts loaded; if they didn't, the site concludes the visitor has a blocker and shows a dismissal prompt. More aggressive versions use bait elements (hidden divs with ad-related class names) and measure whether they were hidden by CSS, which catches element-hiding blockers like uBlock Origin's cosmetic filters.
The counter-response is cosmetic filtering of the detection itself — blocklists include rules for hiding anti-adblock banners and suppressing the detection scripts. Modern uBlock Origin filters like "Fanboy's Annoyance List" handle most cases. DNS-level blockers like Pi-Hole cannot easily defeat anti-adblock because the detection runs from first-party JavaScript on the site itself, which Pi-Hole does not block.
Popunder ad
An advertisement that opens in a new browser window hidden behind the current window, typically triggered by a click on any element of the host page.
Popunders survived the mainstream browser popup blocker because they do not open in the foreground — users often don't notice the extra window until they close the main browser tab and find the ad revealed underneath. Popunder networks (PropellerAds, Clickadu, Adsterra's popunder vertical) pay publishers per-view or per-click; the economics are healthier than display ads for low-end publishers, so pop-unders dominate on link-shortener, warez, streaming, and adult-adjacent sites.
DNS-level blockers rarely catch popunders because the popunder host domain is not on standard advertising blocklists — the host is frequently a short-lived throwaway domain. Browser-extension blockers with cosmetic filtering catch most of them because they intercept the window.open() call that creates the new window. A layered stack (Pi-Hole for the long tail + uBlock Origin for popunder interception) achieves near-complete coverage; either layer alone misses significant categories.
> TEST WHAT YOUR STACK ACTUALLY BLOCKS
The 103-test PIHOLEKILLER gauntlet fires real ad, tracker, fingerprinter, DoH-bypass, and malware requests across 3 tiers. See exactly what reaches your browser.
> RUN THE GAUNTLET →