Recursive resolver caches push a DNS onboarding record from one boolean to five states

The loop is reconciliation. Desired state lives in the tenant record, DNS is the observed external state, and a worker compares the two, submits an idempotent change, waits for authoritative confirmation, and records what happened ^[3]. The sketch puts that wait in the type signature: `DnsAdapter` declares `upsert(change)`, which returns a `changeId`, and a separate `authoritative(change)` that returns a boolean ^[4]. A `changeId` proves only that the provider accepted the request. The post argues a successful API response should not be read as the record being visible everywhere, and that verification should query the authoritative answer and check the expected value ^[5].

Agreement from the authoritative nameserver still leaves the resolvers. Recursive resolvers may keep serving cached data until the record's TTL expires ^[6]. A check against authority and a check through a resolver are two different observations, and the onboarding record carries a state for each ^[7]. A support agent has to see which state applies, when the last check ran, which nameserver answered, and whether the tenant changed the value after verification ^[8].

Without that evidence, the author wrote, an overnight timeout often turns into repeated manual edits, conflicting TXT tokens, and a vague claim that DNS is slow ^[9]. The prescribed behaviour at the deadline is to stop retrying, preserve the evidence, and hand the account a precise next action ^[10]. I think that is the strongest part of the design, because a pipeline that halts and reports is cheaper to support than one that keeps writing.

Ownership decides the policy. In a platform-owned zone, deprovisioning becomes a reviewed state transition ^[12], and the record type in the sketch is a closed union of four literals: A, AAAA, CNAME and TXT ^[23]. Customer-owned zones reverse the trust boundary, so the system's output is an exact instruction set and a verification token ^[13]. "One sentence can save a week: customer-owned zones and platform-owned zones are different products," the author wrote ^[14].

The portfolio that falls below the bar is one administrator creating two subdomains each quarter ^[16], or eight changes a year ^[17]. Five states, an idempotency key and an audit log are more machinery than eight changes need, and the post's alternative for that case is a checklist and a second pair of eyes ^[16]. The rule is presented as the field guide its author uses, and the post does not include measurements from a deployment ^[24]. For it to transfer, the work has to be repeated, parallel and time-sensitive, which the post lists as lease onboarding, building launches, regional cutovers and cleanup after a tenant leaves ^[18].

Mail drags in a dependency of its own. DMARC, defined in RFC 7489, lets a domain owner publish a policy and receive aggregate or forensic reports ^[19]. For accounts that cannot delegate authority or respond to verification requests, the post keeps a documented manual handoff ^[20].