Pi-hole FTL isn’t just a DNS server; it’s the beating heart of Pi-hole, and its real magic lies in how it shatters the traditional DNS lookup process.
Let’s watch it in action. Imagine a user on your network types www.example.com into their browser.
- Client Request: The user’s computer sends a DNS query for
www.example.comto Pi-hole’s IP address (usually192.168.1.2). - FTL Intercepts: Pi-hole FTL, listening on UDP/TCP port 53, immediately receives this query.
- Blocklist Check: FTL checks its local, in-memory list of blocked domains. If
www.example.comis there, it immediately sends back a "NXDOMAIN" (Non-Existent Domain) response, zeroing out the lookup time. - Upstream Forwarding (if not blocked): If
www.example.comisn’t blocked, FTL forwards the query to one of its configured upstream DNS servers (e.g.,1.1.1.1or8.8.8.8). - Upstream Response: The upstream server resolves
www.example.comto an IP address (e.g.,93.184.216.34) and sends it back to FTL. - FTL Caches & Responds: FTL stores this IP address in its local cache, associating it with
www.example.comfor a specified TTL. It then sends the IP address back to the user’s computer. - Client Connects: The user’s browser uses the IP address
93.184.216.34to connect to the web server hostingwww.example.com.
This entire process, especially for cached or blocked domains, happens in milliseconds. FTL’s "Fast Lightweight DNS Engine" moniker comes from its design: it’s written in C and optimized for speed and low memory usage, making it ideal for embedded devices like the Raspberry Pi that often run Pi-hole. It’s not just a simple DNS forwarder; it’s a sophisticated, high-performance DNS resolver with integrated ad-blocking capabilities.
The core problem FTL solves is the inefficient, ad-laden internet experience. By intercepting and resolving DNS queries locally, it can:
- Block Ads: It compares incoming DNS requests against a comprehensive list of known ad-serving domains. If a match is found, it simply returns a "non-existent" domain response, preventing the ad from ever being requested.
- Improve Speed: For domains it has already resolved or that are on its blocklist, FTL provides an immediate response, bypassing the slower round-trip to an external DNS server.
- Enhance Privacy: By acting as your sole DNS resolver, Pi-hole FTL can prevent your ISP or other upstream DNS providers from seeing every website you visit.
Internally, FTL is a multi-threaded application. When it receives a DNS query, it assigns it to a worker thread. This thread first checks the local query database (which includes blocked domains and cached entries). If the domain isn’t found there, the worker thread forwards the query to an upstream DNS server, waits for the response, stores it in the database, and then sends it back to the client. The use of threads allows FTL to handle multiple DNS requests concurrently, significantly increasing its throughput.
The key configuration lever you control is the upstream_dns_servers setting in /etc/pihole/setupVars.conf. This determines where FTL sends queries it can’t resolve locally. Common options include:
# Example /etc/pihole/setupVars.conf snippet
PIHOLE_DNS_1=1.1.1.1
PIHOLE_DNS_2=8.8.8.8
This tells FTL to try Cloudflare’s 1.1.1.1 first, and if that fails or is unreachable, to try Google’s 8.8.8.8. You can also specify local IPs if you’re running your own DNS resolver.
A common pitfall is misunderstanding FTL’s caching. While FTL caches DNS records, it also aggressively caches negative responses (NXDOMAIN). This means if a domain is blocked, FTL will remember it’s blocked for the duration specified in Pi-hole’s gravity settings (which defaults to 12 hours for blocked domains). If you add a domain to your blocklist and expect it to be blocked instantly, but it’s still resolving, it’s likely due to FTL’s negative caching. You can clear this cache manually by running sudo pihole restartdns.
The next critical concept you’ll encounter is how Pi-hole’s query logging and statistics are powered by FTL’s internal database and its ability to track every DNS request.