PowerDNS Authoritative has no dnstap — and what we did instead

We had query analytics on the roadmap with a one-line technical plan: ingest dnstap from PowerDNS, aggregate in a worker, show it in the panel. dnstap is the standard structured logging format for DNS, it is fast, and PowerDNS supports it. Except in the server we actually run, it does not.

The check that took two minutes

Before writing the ingestion code, we asked the running binary:

pdns_server --help | grep -c -- "--"   # 225 options
pdns_server --help | grep -i dnstap    # nothing

Two hundred and twenty-five options, zero mentions of dnstap. It turns out dnstap belongs to the PowerDNS Recursor and to dnsdist — not to the Authoritative server. The documentation that says "PowerDNS supports dnstap" is correct; it just refers to different products in the same family.

What we shipped instead

The authoritative server can log every query as a text line. It is not a stable contract — a version bump can change the format without warning — so we put the parser behind a port, the same way the DNS backend itself sits behind one. The day dnsdist is in front, we swap the adapter and the model, aggregation, endpoint and UI stay untouched.

The line looks like this, and it carries the client IP:

Remote 203.0.113.10 wants 'example.com|A', do = 0, bufsize = 1232: packetcache MISS

We discard that IP on the way in. Analytics for DNS does not need to know who asked, and keeping it would build a pile of personal data with no purpose. What we store is the count per zone, name, type and hour.

The honest consequence

A query log records the question, not the answer. So there is no rcode breakdown — and our pricing table used to promise "volume, tops, rcodes". We removed the promise instead of inventing the number. When a structured source exists, the field comes back.

The lesson is not about dnstap. It is that a one-line technical plan is a hypothesis, and the cheapest moment to test it is before the code exists.