DNS Log Monitoring:
Real-time Query Logging

DNS Logging: Seeing What the Internet Asks About Your Domain

Every time someone visits a website, their computer first asks a DNS server: "what's the IP address for this domain?" That query is normally invisible — it happens behind the scenes, logged only by DNS resolvers that you don't control. But with a DNS logging service, you can see these queries in real-time. You get a subdomain, and any DNS lookup for that subdomain — or anything under it — gets logged. Someone pings your subdomain? You see it. A server resolves it as part of an SSRF attack? You see it. A mail server checks SPF records that include your domain? You see it. DNS logging turns an invisible infrastructure layer into observable data.

Our DNS Log Monitor page connects you to dig.pm, a free DNS logging service. You get a random subdomain like a1b2c3.dig.pm. Use that subdomain anywhere DNS queries happen — as a webhook URL, in an email header, as an SSRF payload target. Every DNS query appears in the log with its timestamp, source IP, query type, and full domain.

How DNS Logging Works Technically

dig.pm (and similar services like dnslog.cn, Burp Collaborator, and interactsh) runs an authoritative DNS server. When you get a subdomain, that server is configured as the authoritative nameserver for your subdomain and everything beneath it. Any DNS resolver trying to look up your-subdomain.dig.pm eventually reaches dig.pm's authoritative server. That server logs the query and returns a response (typically an A record pointing to a controlled IP address). The log entry tells you: someone, somewhere, tried to resolve this domain. Their DNS resolver's IP address is recorded, giving you the approximate geographic origin of the query.

This technique exploits a fundamental property of DNS: queries are forwarded through a hierarchy of servers until they reach the authoritative source. You control the authoritative source for your subdomain. Every query that reaches you is evidence that someone (or something) initiated a DNS lookup. The query itself doesn't tell you why — it could be a human typing a URL, an automated scanner checking domain reputation, or an exploited server making an outbound request as part of an attack. Interpreting the query's meaning requires context about how you used the subdomain.

Security Testing with DNS Logs

Out-of-Band (OOB) vulnerability detection. This is the primary security use case for DNS logging. When testing for vulnerabilities like XML External Entity (XXE) injection, Server-Side Request Forgery (SSRF), or blind command injection, you can't always see the result of your payload directly. The server processes it, but the output goes to a log file, an email, or nowhere at all. DNS logging gives you an out-of-band channel: include your subdomain in the payload. If the server processes the payload and triggers a DNS lookup, you see it in the log. This confirms the vulnerability exists, even when you can't see any other output.

For example, testing for XXE: inject an XML entity that references http://test123.your-subdomain.dig.pm/. If the XML parser processes external entities, the server makes a DNS query to resolve your subdomain. You see the query in the log. The vulnerability is confirmed. Without DNS logging, this blind XXE would be invisible — the server processes the XML, the entity is resolved, but no error or output is returned to you.

SSRF testing. Same principle. If an application accepts a URL from user input and fetches it server-side, provide your DNS log subdomain as the URL. If the server resolves it, you have SSRF. By using different prefixes for different test inputs (test1.a1b2c3.dig.pm, test2.a1b2c3.dig.pm), you can correlate DNS queries back to specific test cases — knowing which input triggered the request is essential for reproducing and reporting the vulnerability.

DNS Propagation Monitoring

Beyond security testing, DNS logs help monitor DNS propagation. Change an A record for your domain from an old IP to a new IP. Use a DNS log service with a subdomain that delegates to the same nameservers. Set up a monitoring script that periodically resolves your domain from different geographic locations. As the change propagates, each resolver picks up the new record at a different time. The DNS log shows exactly when each resolver switched from the old IP to the new one, giving you propagation timing data that's specific to your domain and your users' resolvers.

This is more practical than the generic "DNS propagation takes 24-48 hours" advice. For a domain with a 300-second TTL, propagation might complete in 5-10 minutes on major public resolvers. For a domain with a 86400-second TTL (24 hours) that you forgot to lower before making changes, propagation genuinely takes that long. DNS logging gives you visibility into this process. For comprehensive DNS diagnostics beyond logging, pair this with our DNS Lookup tool for record inspection and our WHOIS Lookup for domain ownership verification.

Privacy and Ethical Use

DNS log services generate random subdomains accessible to anyone who knows them. The subdomain token is your only access control — anyone who guesses or sees your token can view your DNS logs. Keep tokens private. Don't use DNS logging to track real users without their knowledge and consent. DNS logging is a diagnostic and security testing tool, not a surveillance mechanism. For production monitoring of your own infrastructure, use proper DNS analytics services. For security testing, use DNS logging responsibly and only on systems you own or have explicit permission to test.