The Pi-hole query log doesn’t just show you what’s being blocked; it reveals the entire conversation your devices are having with the internet, often in surprising ways.
Let’s see it in action. Imagine a smart TV, a phone, and a smart speaker are all on your network.
# Example Pi-hole tail -f /var/log/pihole/FTL.log output
1678886400 192.168.1.101 192.168.1.101 0 googleads.g.doubleclick.net "" A
1678886401 192.168.1.101 192.168.1.101 0 googleads.g.doubleclick.net "" AAAA
1678886405 192.168.1.102 192.168.1.102 0 amazon-dns.com "" A
1678886406 192.168.1.102 192.168.1.102 0 amazon-dns.com "" AAAA
1678886410 192.168.1.103 192.168.1.103 0 vocaltune.spotify.com "" A
1678886411 192.168.1.103 192.168.1.103 0 vocaltune.spotify.com "" AAAA
1678886415 192.168.1.101 192.168.1.101 0 www.google.com "" A
1678886416 192.168.1.101 192.168.1.101 0 www.google.com "" AAAA
1678886420 192.168.1.102 192.168.1.102 0 device-metrics-us.amazon.com "" A
1678886421 192.168.1.102 192.168.1.102 0 device-metrics-us.amazon.com "" AAAA
1678886425 192.168.1.103 192.168.1.103 0 audio.spotify.com "" A
1678886426 192.168.1.103 192.168.1.103 0 audio.spotify.com "" AAAA
In this snippet, you can see:
192.168.1.101(likely the TV) is queryinggoogleads.g.doubleclick.netandwww.google.com.192.168.1.102(the smart speaker) is hittingamazon-dns.comanddevice-metrics-us.amazon.com.192.168.1.103(the phone) is talking tovocaltune.spotify.comandaudio.spotify.com.
Each line represents a DNS query. The fields are: timestamp, client IP, Pi-hole IP, query type (A for IPv4, AAAA for IPv6), domain name, and a flag (usually empty for standard queries).
The query log is your network’s Rosetta Stone for understanding device behavior. It tells you what services devices are trying to reach, even when they’re idle. This is invaluable for identifying unwanted tracking, telemetry, or even rogue applications. By analyzing patterns – which devices query what, how often, and at what times – you can build a comprehensive picture of your network’s "chatter."
You can use this data to:
- Identify Ad/Tracker Sources: See exactly which devices are making requests to known advertising or tracking domains.
- Detect "Phone Home" Behavior: Uncover devices that are sending data to their manufacturers or cloud services more than you’d expect.
- Troubleshoot Connectivity: Determine if a device can’t reach a service because its DNS resolution is failing.
- Optimize Blocklists: Add or remove domains from your blocklists based on observed traffic, tuning your network’s privacy.
The system behind the query log is primarily pihole-FTL (Faster Than Light), the core processing engine of Pi-hole. It listens on port 53 for DNS requests, forwards them to upstream DNS servers (if not blocked or cached), and logs the details. The web interface then queries pihole-FTL’s database (often stored in /etc/pihole/pihole-FTL.db or a similar location) to display this information.
To get a deeper understanding, you can query the FTL database directly. For example, to see the top queried domains by a specific client over the last 24 hours:
# Install sqlite3 if you don't have it
sudo apt update && sudo apt install sqlite3 -y
# Connect to the FTL database and run a query
sqlite3 /etc/pihole/pihole-FTL.db "SELECT domain, COUNT(domain) as count FROM queries WHERE client = '192.168.1.103' AND timestamp > (strftime('%s','now') - 86400) GROUP BY domain ORDER BY count DESC LIMIT 10;"
This command uses sqlite3 to access the Pi-hole database. It filters queries by the client IP 192.168.1.103, looks at requests made in the last 86400 seconds (24 hours), groups them by domain, counts them, and shows the top 10.
The real power of the query log lies in its temporal and source-based analysis. It’s not just a static list; it’s a stream of network activity. You can filter by time, by client, by domain, and by status (blocked/allowed). Looking at the rate of queries is often more revealing than just the total count. A sudden spike in queries to a specific domain from a device that was previously quiet can indicate a background update or a new service starting up.
Most users don’t realize that the status field in the queries table of the pihole-FTL.db database (which you can see with the sqlite3 command above) isn’t just a simple "blocked" or "allowed." It actually contains an integer code. A status of 0 means the query was answered (either by cache or upstream). A status of 1 means the query was blocked by a domain list. However, there are other less common codes, like 2 for gravity updates and 3 for DNSSEC validation failures, which can point to different kinds of network issues or configurations that are not immediately obvious from the web interface’s "Blocked" column.
Once you’ve mastered analyzing the query log for individual device behavior, the next step is to correlate these patterns across multiple devices to understand inter-device communication or network-wide service adoption.