Logging and monitoring a DNS server
A DNS server rarely fails outright: it slows down, returns errors, or keeps repeating false answers from its cache. Logs and a handful of well-chosen metrics make those drifts visible before they turn into incidents for users.
What a query log contains
A query log records, for every question received, the name requested, the type, the client address, the answer returned and sometimes the processing time. It is the raw material of diagnosis: it shows who is asking for what, and makes it possible to tell a zone fault from a resolver fault. Without it, analysis is limited to probing from the outside.
This content is also sensitive data. An IP address associated with a queried name is personal data within the meaning of the European data protection regulation: its collection must have a purpose, a retention period and restricted access. Logging everything, indefinitely, on an accessible server exposes the organisation without improving diagnosis.
Good practice is to enable query logging for limited periods, during a diagnosis, rather than permanently. Where a lasting analytical need exists, retention is limited to a few days and the logs are restricted to the people who have use of them.
Enabling traces without drowning in them
Modern name servers separate message categories: configuration errors, zone transfers, queries, dynamic updates. Enabling everything means producing a considerable volume and burying what matters. You enable the operational categories first, then the query category only when a specific question arises.
The volume calls for automatic rotation and purging. A query log on a moderately busy server runs to gigabytes per day; without rotation, it fills the partition and the server stops working for a reason unrelated to DNS. The maximum size, the number of archives and the purge must be set before the first activation.
Some servers offer a structured export of events, more usable than a text log: each query becomes an object with its fields, directly indexable by an analysis tool. This format costs a little configuration but avoids the rewriting work that comes with text logs.
The metrics that matter
Four families are enough. The query rate per second gives the load and reveals an abnormal increase. The share of error responses, in particular server-side resolution failures, measures the real health of the service. The share of negative responses distinguishes an incomplete zone from malformed traffic. Processing latency signals saturation before it becomes visible.
Replication metrics come on top of these: identical serial number on every server, age of the last copy, transfer failures. A server that answers perfectly but whose copy is several days old is an incident in the making, invisible in conventional availability metrics.
Recognising abnormal traffic
An open recursive server, one that answers the whole internet, is used in amplification attacks: the attacker sends queries with a spoofed source address towards many targets. The incoming traffic looks ordinary; only the distribution of destinations betrays the use. The first measure remains refusing recursion to clients not entitled to it.
Authoritative servers suffer another form of traffic: massive queries for random names, intended to saturate the negative cache or the link. The software offers response rate limiting, which reduces the load by grouping identical responses. This limiting must be tuned cautiously: misconfigured, it degrades service for legitimate resolvers that query heavily.
In both cases, the log is the evidence. Without a trace, the only option is to block broadly, at the risk of cutting off real users. With a trace, you target a prefix, a query signature, or you establish that the problem lies elsewhere.
Monitoring from the outside
Internal monitoring measures the machine; external monitoring measures the service. Having a canary name resolved by several resolvers, from several networks, at regular intervals, detects a delegation failure or a wrong answer that no local metric would show. This check must bear on a name in the zone itself, not on a generic name.
Certificate monitoring must be added when the server exposes DNS over TLS or DNS over HTTPS: an expired certificate cuts the service without DNS itself being at fault. And clock monitoring: drift invalidates the signatures of a signed zone, with an effect identical to an outage.
These checks complement each other: the external probe says a user cannot resolve, the log says why. Keeping the two apart avoids hunting through the logs for an outage that sits with the access provider, or the reverse.
What not to measure
The temptation is to track a propagation metric after a zone change. That metric does not exist: each cache expires at its own pace, and aggregating spot observations produces a meaningless figure. The useful tracking is that of the content published by the authorities, supplemented by tests from a few representative resolvers.
Likewise, a high number of queries is not a problem in itself, and a low number is not proof of good health. Metrics are read against a baseline specific to the server, established over time. Comparing your traffic with that of another server teaches you almost nothing.
References
- https://www.rfc-editor.org/rfc/rfc8499.html
- https://www.rfc-editor.org/rfc/rfc1035.html
- https://bind9.readthedocs.io/en/latest/
To check a domain name live — root, TLD, name servers — use the DNS test tool. Demarcq.net runs DNS servers: managed DNS operations.