The Registry Is Identity

"A machine's name is where it answers. Its identity is who you decided it is."

Identity you assign, not identity you find

The canonical identity of a managed machine is a stable host_id that you chose and wrote into the registry. It's a decision, made once, that outlives every network change the machine will ever go through. Nothing the machine reports about itself gets to overrule it.

Binding evidence vs mutable observation

Two kinds of facts attach to that id. Binding evidence — hardware identity, the tailnet node id — proves this is the same physical Mac across reinstalls and renames; it's how re-enrollment knows it found the original. Mutable observations — hostname, IP address — are just where the Mac answers today. The first kind anchors identity; the second kind must never be identity.

Why a hostname or IP can't be the key

Hostnames get renamed on a whim. Dynamic addresses rotate — Tailscale's especially. Two machines can wear the same name across a wipe-and-reinstall. Hardcode an address as identity, and the day it changes your registry silently re-points at the wrong Mac or loses the right one. An identity that moves isn't an identity; it's a rumor with good uptime.

Re-enrolling the same Mac

Because identity is the assigned host_id bound to hardware evidence, wiping a Mac and enrolling it again restores its record and history — it doesn't mint a look-alike duplicate card beside the old one. The machine you rebuilt is still, provably, the machine you had.

Anchor identity to what can't drift. Bind to hardware and node evidence; treat every name and address as a place the machine is, never a name for what it is.

Code

One machine, three kinds of fact·json

{
  "host_id": "server",                     // <- CANONICAL identity: you chose it
  "display_name": "Always-on server",
  "binding_evidence": {                     // <- proves "same physical Mac"
    "hardware_id": "stable-serial-...",     //    binding, survives reinstall
    "tailscale_node_id": "stable-node-..."  //    binding
  },
  "observed_addresses": {                   // <- MUTABLE, never identity
    "hostname": "renamed-on-a-whim.local",
    "ipv4": "handed-out-by-dhcp"
  }
}
// Identity is the host_id, anchored to hardware/node evidence.
// Addresses are just where the Mac happens to answer today. If you
// ever join two records by ipv4, you have joined by 'today.'

Exercise

Pick two machines you own. For each, write one fact that is truly stable (a hardware serial, a provisioned key id) and two facts that drift (its name, its current IP). Which would you build your records around — and what breaks the first time the drifting ones change?

Hint

If your notes say 'the Mac at 192.168.1.42,' you've keyed on an address. The day DHCP hands that address to the printer, your notes now describe the printer — and nothing warns you.

Identity you assign, not identity you find

Binding evidence vs mutable observation

Why a hostname or IP can't be the key

Re-enrolling the same Mac

Code

External links

Exercise

Progress

Comments 0