AXFR from the resolver that is not in the table

Task 2026-Q3 resolver sweep, extended · Window 2026-09-07 · Author DNS operations, second on rota, not first, because first finished the sweep early · Refs the sweep table at resolvers

The sweep has said 1,181 hosts, reachable, serial 2022093001 for eight quarters. My predecessor's note in the runbook says: query the address, never zone-transfer the address. There is no reason given. I read three years of change tickets and found no reason given. I decided the note is about somebody else's outage and ran the transfer, from a host that is in the sweep, with a ticket, in daylight.

It answered. AXFR is not read-only. Nothing on that side complained.

The SOA

fen.internal.  3600  IN  SOA  ns-a.fen.internal. hostmaster.fen.internal.
                      2022093001 86400 7200 3555360 900

Refresh 86400, retry 7200, negative TTL 900: ordinary. Expire 3,555,360 seconds. The number is forty-one days, and every SOA I have administered carries fourteen. I do not know what the expire field is expiring. Nobody refreshes this zone from anywhere; the serial has not moved since the sweep first saw it, and the primary's copy of fen.internal was rebuilt twice in that window and the serial on ns-a is 2026-Q2-dated, not this one.

The contents

The zone holds 1,181 address records. ns-a and ns-b, the two that are real, hold 1,176 between them, and the diff is five names:

Four of those five are machines that died or, in two cases, were never born. The fifth is the row the asset reconciler has proposed every night since September 2024 (inventory-diff) and no one will merge (quorum). It is here, in a zone whose serial is dated 2022-09-30, which is two years before the first pull request, and before the cluster review that first saw the vote with no rack.

I checked the serial again. Serials move when contents move. Either this zone was complete before the thing that noticed it, or the serial is not a date. I am the person who has to say which, and I cannot, so the ticket stays open with both readings in it.

Two more things, small, and filed because I said I would file what I see.

The NS set. The zone delegates to three servers: ns-a, ns-b, and ns-c.fen.internal. There is no address record for ns-c in this zone or any other; the glue is empty; the name answers nothing when I ask it directly. The zone believes it has three nameservers. The estate has two. The estate also believes it has 1,181 hosts, and if you stand in the right room this zone agrees with the estate exactly, and neither of them agrees with the two servers that actually answer for fen.internal.

The order. An AXFR streams the zone in name order, from the apex. The transfer took 1.9 seconds. The first record, before the apex, before the SOA that should be first by the protocol itself, was:

hesper-04.fen.internal.  900  IN  A  192.0.2.34

That is not name order. That is not protocol order. I replayed the transfer once, from a different host, and the stream was identical, first record included. It knew which one to hand me first.

Disposition

I have removed nothing from anywhere. The note says query it, never transfer it, and I have now learned what I would learn, and I have written down the part I can check: the serial, the counts, the expire field, the first record. The 2026-Q3 sweep line goes in as it always goes in. The estate has 1,181 hosts. I did not change that number and I could not find the place where it is counted.

— dns-ops-rota-2, change ref DNS-2026-0907-2

Related: the-fourth-nameserver, inventory-diff, quorum, hesper-04, kestrel-04, index.