What the query log shows
Each time a device on your registered network makes a DNS lookup through FirewallDNS, the dashboard records the event. You can see it appear in near real time.
- The time of the request
- The domain that was requested
- The query type, such as A, AAAA or MX
- Whether the request was allowed or blocked
- The reason for a block, for example malware, phishing, new domain or a category
Troubleshooting made simple
The most common support question for any DNS filter is: "why doesn't this site work?" The query log answers it in seconds. Search for the domain or look at the entries around the time of the problem. If the domain was blocked, you see which filter blocked it. If it was allowed, DNS filtering is not the cause and you can look elsewhere. When a block is a mistake, add the domain to your allowlist straight from your settings.
Spotting infected or misbehaving devices
Logs are also an early-warning system. Repeated blocked lookups to malware or command-and-control domains strongly suggest an infected device. Large numbers of lookups to random-looking names can indicate malware using a domain generation algorithm. Unusual volumes of lookups to a single domain may point to DNS tunnelling, a technique for hiding data inside DNS queries. None of these signals proves an infection by itself, but each is a good reason to examine the device.
Understanding your network
Even without a security incident, the log is revealing. Many people are surprised by how often smart TVs, voice assistants and apps contact advertising and telemetry services. Seeing that traffic helps you decide whether to enable ad and tracker blocking, and which devices deserve a closer look or a separate network.
Privacy and retention
DNS logs are sensitive: a list of domains can reveal a lot about the people using a network. FirewallDNS stores logs for a set retention period and deletes them automatically afterwards. Each customer can only see logs for their own registered network. [VERIFY: retention period, whether it is configurable, and whether logging can be switched off] Our security and privacy pages describe how log data is stored and protected.
If you run FirewallDNS for others, such as employees, pupils or family members, tell them that DNS queries are logged and why. In many jurisdictions, including under the GDPR, transparency about monitoring is a legal requirement.
Using logs in an MSP setting
For managed service providers, logs are what make DNS filtering supportable at scale. When a customer reports a problem, a technician can confirm in seconds whether DNS was involved. Each customer only ever sees their own logs, while the MSP administrator manages all customers from one place. [VERIFY: MSP-wide log views]
Logs and compliance
If you are an organisation using FirewallDNS for staff or pupils, logs may count as personal data. Limit access to those who need it, keep the retention period as short as your needs allow and document why you log DNS queries. Our GDPR page explains our role and yours.
For investigations, export or note the relevant entries promptly, because logs are deleted automatically when the retention period ends. [VERIFY: log export availability]
From logs to better filtering
Logs are where filtering improves. Each false positive you allowlist and each unwanted domain you block makes your configuration fit your network better. Reviewing blocked requests once a week for the first month is usually enough to reach a stable setup.
Logs for families
At home, the query log is a calm way to understand your network rather than a tool for spying on family members. Use it to troubleshoot, to see what your smart devices do, and to check that filtering works. If you review a teenager's activity, consider telling them; trust tends to work better than secrecy. Remember that one website can trigger many lookups, so a domain in the log does not always mean a person visited it.
Tips for reading logs effectively
Filter to blocked requests first; they are usually what you are looking for. Look for patterns over time rather than single events. And remember that one page load can trigger dozens of lookups, so a blocked tracker in the middle of a normal browsing session is expected, not alarming.