Summary

  • At APNIC 62, ISC presented Stork’s DNS zone listing and serial-mismatch detection as capabilities available today. The presentation did not document an APNIC production deployment or a real stale-zone incident.
  • A mismatch is evidence about the server, view and zone rows that Stork discovered and fetched. A clean list is not an estate-wide result unless the record also preserves failed fetches, unsupported views, exclusions and cache age.
  • The useful operating object is a comparison receipt: Stork and daemon versions, intended and observed scope, fetch status, raw SOA serials, observation time, freshness limit and the disposition of every unavailable row.

The row that is absent cannot disagree

A DNS serial mismatch is attractive evidence because it is compact. The same zone appears on two servers; the SOA values differ; one row becomes conspicuous. At APNIC 62, Marcin Siodelski’s Stork presentation placed zone listing and filtering, a zone viewer and “Serial Mismatch Detection” in the product’s current DNS feature set. APNIC’s subsequent session report described the same cross-server signal.

That signal deserves to be used. It also needs a denominator.

Stork does not observe an abstract DNS estate. It observes daemons that its agents can detect, configuration and interfaces they can read, and zone information that the Stork server has asked those agents to fetch. A row that never entered that chain cannot display a mismatch. It cannot display agreement either.

The boundary begins with discovery. In the Stork 2.4.1 DNS documentation, the agent locates a running BIND 9 process and then finds the configuration used by that process. If it cannot find that configuration, the daemon is not placed on the detected-daemon list. For the zone viewer, BIND’s statistics channel is mandatory: Stork uses it to retrieve configured views and zones. PowerDNS follows a different path through its webserver API and configuration key.

None of those requirements is proof of a defect. A daemon may be outside the intended monitoring scope. A configuration may be deliberately unreadable to the agent. An endpoint may be disabled by policy. The point is narrower: the scope of the result is the scope that successfully crossed those boundaries, not every authoritative server an organisation owns.

The next boundary is time. Stork’s zone list is fetched into its own database. The documentation says the list starts empty, the operator invokes Fetch Zones, and the stored list is not refreshed automatically. To see an updated list, the operator fetches again. Fetch Status exposes errors and supplies counts for zone configurations, distinct zones and built-in zones.

Those counts are not interchangeable. If one zone name appears in three views, it is one distinct zone and three zone configurations. A receipt that retains only the distinct-name count can lose two comparison surfaces. A report that retains only the configuration count can hide whether the apparent increase came from more names or more views. Both values, and the rule that produced them, belong beside the result.

Views make the identity problem concrete. For BIND 9, Stork can associate the same zone name with different views. When an operator asks to inspect the records through AXFR, a non-default view needs a TSIG key so that BIND can tell which view the request belongs to. The configuration’s match-clients and allow-transfer rules determine the usable key. In PowerDNS 5.0, views are explicitly not supported by Stork 2.4.1. An unavailable PowerDNS view is therefore a documented product boundary, not a serial agreement.

Two data paths should remain separate. The zone list and its serials are gathered through the DNS server integrations and cached after Fetch Zones. Zone contents are fetched on demand when a user selects Show Zone; that operation uses AXFR and may reuse a cached copy until Refresh from DNS is requested. A failed AXFR can prevent record browsing without necessarily erasing a serial already present in the zone list. Conversely, a visible serial does not prove that Stork successfully obtained the complete records. Merging the two paths would turn one observable into a claim about another.

The same discipline applies to transfer monitoring. Siodelski’s deck labels XFR monitoring as new in development version 2.5.1. The 2.5.1 agent manual says that this BIND-only log tracking is disabled by default, must be enabled explicitly, and cannot track transfers recorded only through syslog. It is not the same feature as the stable 2.4.1 serial comparison. ISC currently lists 2.4.1 as stable and 2.5.1 as development on the Stork product page. A dashboard claim should therefore carry its product version rather than borrow capabilities from a neighbouring release.

The serial itself also needs careful language. RFC 1912 explains why a secondary checks the primary’s SOA serial before requesting newer data. RFC 1982 defines 32-bit serial arithmetic: values wrap, and ordinary integer ordering is not enough. Equality is unambiguous, but deciding which unequal value is newer requires the RFC’s sequence-space rules; an exact half-space pair has no defined order.

The reviewed Stork material supports mismatch detection. It does not establish which ordering label, if any, Stork assigns to every pair. A durable record should therefore retain both raw serials and any implementation-produced ordering result. “Different” is supported by inequality. “This server is behind” needs the comparison rule, observation time and server role.

Serial equality has another familiar limit: it does not prove that every record is identical, that DNSSEC validates, or that a client is receiving the intended answer. Those questions are important, but they are not this article’s commission. The narrower Stork question comes first. Before asking what equal serials prove, establish which rows were present to be equal.

A comparison receipt can stay compact. It should name the Stork server and agent versions, DNS implementation and daemon version; identify the machine, daemon, zone, class and view without publishing secrets; state the intended inventory and who owns it; record the fetch window and per-daemon status; retain Zone Configs Count and Distinct Zones; list explicit exclusions and unsupported view states; store the raw serials, cache or observation time, freshness limit and result; and preserve the alert decision and any later correction.

That receipt should allow four outcomes rather than one green lamp: complete for the declared scope, partial because rows were unavailable, stale because the inventory exceeded its freshness limit, or not comparable because the set changed. A mismatch can still be actionable inside a partial result. An absence of mismatches cannot be promoted beyond the coverage the receipt proves.

This is not an argument against Stork. It is the operating discipline that makes a central view valuable. The product can join information that would otherwise be scattered across many DNS servers. The operator supplies the missing institutional fact: which servers and views were supposed to be in that join. Once the observed set and the expected set travel together, a highlighted discrepancy becomes more than a useful screen. It becomes a reproducible decision record.

Sources