DNS ownership

Who may write which record in a zone the factory touches, and how the factory tells its own records from everyone else’s. For host owners; the repository side is hostnames in the dev-container file, the host side dns in the host spec.

The tag

Every record the factory writes carries an ownership tag in the record’s comment field at your DNS provider:

managed-by=factory/<host id>

<host id> is the id of the host spec. The tag is the ONLY thing the factory consults before it updates or deletes a record. Name, type and content are never enough: a record that merely shares a name with one of ours is somebody’s record.

There is one tag per host, not per pod or per engineer. A host’s pods are provisioned by many people with one credential; the unit of ownership is the thing that holds the credential.

Two kinds of record

Pod records are deliberately not part of the host’s state: many engineers provisioning in parallel would otherwise queue on one host, and each provision would be a change to the entire host. So the ownership check lives in the write itself, before every record.

What a provision does, per public hostname

The set is the pod’s hostnames.default plus one hostnames.port name per public: true port that is neither default nor path-routed, over every member. A private port has no hostname and no record. Each is a proxied CNAME to the host’s private tunnel.

flowchart TD
  q{"What does the zone hold<br/>under that name?"}
  q -- nothing --> c["<b>created</b>, tagged"]
  q -- "ours, already correct" --> u["<b>unchanged</b> — no write"]
  q -- "ours, stale" --> up["<b>updated</b> in place"]
  q -- "an untagged CNAME<br/>(hand-made, or legacy)" --> a["<b>adopted</b>: updated in place,<br/>the tag added — never duplicated"]
  q -- "tagged by another<br/>host or tool" --> r1["<b>refused</b> — warned, left untouched"]
  q -- "not a CNAME<br/>(A, TXT, …)" --> r2["<b>refused</b> — it is someone's real record"]

Adoption is what lets a repository move from hand-managed records to the factory without an outage: the first provision claims the existing name and from then on the record is the factory’s. It is narrow on purpose (CNAME only, never over another owner’s tag) so that a typo in a template cannot capture an unrelated record.

What a teardown / purge does

Deletes every record under the pod’s hostname set that carries this host’s tag. Anything else under those names is reported and left alone — including an untagged legacy record, because teardown never adopts. A refusal is a warning, not a failure: the pod is down either way, and a foreign record is the zone owner’s to sort out.

What the credential can do

dns.tokenFrom needs DNS edit on every zone in dns.zones[] and nothing more. The factory never lists a zone’s records wholesale — every lookup is by exact name — so a token scoped to the listed zones is the whole blast radius. A name in a zone outside dns.zones[] is refused at validate, before any credential is used.

Recognising a factory record in your dashboard

Filter the zone’s records on the comment managed-by=factory/. The value after the slash names the host; two hosts writing into one zone are told apart by it, and neither touches the other’s records.

Deliberately not here

• No wildcard. *.<zone> → tunnel would make every hostname resolve, including ones no pod serves (a 404 that looks like a dead environment). One record per served hostname, created and removed with the pod, is the observable state.
• No record for private ports. Reachable inside the pod and over your private network only.
• No private-network name records. ssh developer@dev-alice resolves on your private network’s own name service; the pod’s device name is matched exactly on removal and is not a zone record.