Property offboarding waits out the old 3,600-second TTL before it deletes one leasing record

Two clocks run during an offboarding. The control plane accepts a mutation on its own schedule, and recursive resolvers keep the prior answer for as long as the TTL they were handed says to keep it ^[4]. Treating the mutation response as completion collapses those clocks, and an intermittent result then looks mysterious ^[4]. The post is a design argument for a property-management console; the supplied text does not name a DNS provider or describe a specific outage ^[20].

The wait has to be derived from the old TTL recorded in the plan, because lowering a TTL does not retroactively shorten answers already cached ^[12]. In the worked example the old value is 3,600 seconds and the cutover value is 300 ^[14]. A resolver that fetched the record a second before the change can hold it for nearly the full hour ^[14]. Gate the `ready` transition on 300 seconds and you have opened the delete window 3,300 seconds early ^[1]. For 55 minutes, some resolver still answers with the address you are about to remove ^[1].

Lowering the TTL has a running cost while the lower value is in force. The post says the pre-cutover drop narrows the later cache window and increases query frequency ^[15]. Divide 3,600 by 300: a cache that refetches on expiry now asks twelve times as often for every name in the lowered set ^[2]. The post states the trade both ways, lower TTLs for cutover responsiveness and higher TTLs for fewer refreshes, and neither setting makes a zone-wide delete safe ^[19].

Scope is settled before any of that. The plan is immutable, carries a unique operation ID and records the expected current value for every record, and the mutation worker stops instead of deleting when live state differs ^[11]. What it reviews first is an inventory of name, type, value, TTL, property ID and lifecycle state ^[10]. Compare-and-delete as described is a read, a comparison, then a delete. Unless the provider API accepts a precondition on the record's current value, a change landing between the read and the delete still gets through. The check shrinks that window, and a race still fits inside it. The Go sketch accepts a previously reviewed plan and rejects zone deletion for shared ownership ^[18].

The wide failure is mail. DMARC policy is published in DNS and can apply at an organizational-domain boundary, so removing a parent-zone policy during one property's exit can affect mail handling beyond the departing site ^[9]. In the post's example, oak.example.net's leasing site is the thing leaving while `_dmarc.example.net` and the mail-related names still protect or route traffic for the portfolio ^[8]. A shared zone can also be serving leasing pages, resident portals and maintenance integrations for several buildings at once ^[5]. In a shared zone the post denies zone deletion by policy and writes: "No checkbox should bypass that distinction." ^[13]

For the design to transfer, every record in the zone has to carry a property ID and a lifecycle state that something keeps current ^[7][10]. Where records were made by hand, or by three pipelines that do not know about each other, the expected-value check fails closed and the offboarding stalls. Stalling is the behaviour you want at 3 a.m., and it still ends in a page. The author wrote that this is the rule he would want in the runbook when a property manager clicks Offboard at 3 a.m. ^[17]. The page the post asks for names the failed record checks and the affected properties ^[6].