The registry, and how it federates

Calling it "the registry" hides the fact that one service currently performs three functions with completely different trust, scale and freshness profiles. Separating them is most of the deployment story.

The first is an authority question and must be answered consistently by whoever owns the namespace. The second is soft state that expires on its own. The third is a momentary service that holds nothing. In a mature deployment these are three services, possibly run by three different parties.

Keeping them distinct matters more than it sounds. Conflating authority with liveness produces a specific and nasty failure: if a binding expires because a machine went quiet, then switching a machine off is indistinguishable from giving up its name. The two lifetimes must be independent — an endpoint may be forgotten in a minute, while ownership persists for a year.

The comparison is a good instinct, and it is right about mechanism: like ARP, the location directory is soft state about liveness. An entry says "this identifier is reachable over there", it is refreshed by activity, and it expires when the host goes quiet.

The difference is the one that matters. ARP has no concept of ownership. Whoever answers "that's me" is believed — which is exactly why ARP spoofing works and why every serious network deploys mitigations for it. A DNX name is bound to a key, so answering is not enough: you have to sign.

The unit of registry authority is the zone, not the domain and not the machine. Whoever operates a name in the hierarchy runs the registry for everything beneath it, and delegates the branches below to whoever operates those.

This is where the design turns out to be self-consistent in a way that is genuinely useful: the same tree serves three purposes at once. A level in the name is a routing tier, a delegation boundary, and a unit of authority. That is not a coincidence engineered in — it falls out of using the namespace as the topology.

com.                       ← delegates, stores nothing else
└── dnxroute.com.          ← authoritative for *.dnxroute.com
    └── dnx.dnxroute.com.  ← may delegate further, or serve leaves directly
        └── host1          ← a node with a key

So the short answer to "does everyone need a registry" is no. Every namespace operator needs one. A company runs a registry for its own names, entirely inside its own network if it prefers, and nobody outside needs to know it exists unless names beneath it are meant to be publicly resolvable.

Two models exist, and DNS already ran the experiment.

Referral. Each registry answers only for its own zone and refers the asker downward. The resolver walks the tree. Registries hold no data about anyone else's namespace, so there is no consistency problem between them and no trust required across administrative boundaries. This is what DNX implements.

Three conditions make a referral safe, and all three are enforced rather than assumed. It must be signed by the registry currently trusted — the signature covers the child registry's address and its key, because those are what will be believed next. The delegated zone must contain the name being asked about, or the referral is misdirection. And each hop must narrow: a registry given one branch must never be able to refer for the branch above it, a sibling, or anything unrelated, or delegating a small part of a namespace would be a route to seizing all of it.

The comparison is label-wise, which matters more than it sounds. A plain suffix test reports that evil-dnxroute.com ends with dnxroute.com, and would hand authority over a namespace to whoever registered a similar-looking name.

Replication. Registries share bindings so lookups resolve locally. Faster, but now every pair of registries has a consistency problem, and each must trust data authored by the other. Between mutually distrusting organisations, that is a hard problem wearing a friendly hat.

DNS chose referral plus caching, and DNX should almost certainly do the same. The added wrinkle is that DNX records carry keys, which means a referral chain can be signed end to end — a parent can vouch for the delegation to its child, so a resolver can verify the whole path rather than trusting each hop.

There is a real tension here worth stating plainly, because it threatens something DNX claims as an advantage.

Records are fresh within seconds only because every resolution reaches the authoritative registry. Introduce caching for scale and staleness returns — the exact failure mode DNX criticises DNS for.

The resolution is that the two halves of a record have opposite profiles:

• Name → key. Stable, changes effectively never, and is self-verifying because everything signed with it can be checked. Cache it for days.
• Name → endpoint. Volatile, changes whenever a host moves or its NAT mapping rotates. Cache briefly or not at all.

Splitting the record splits the problem. It also reinforces the argument from section 1: the naming authority and the location directory want to be different services, because one is a slow-moving ledger and the other is a fast-expiring cache.

One registry, inside the perimeter, authoritative for the organisation's namespace. Nothing is published outward. This is the easiest deployment and needs no federation at all — the organisation is the whole world as far as its registry is concerned.

Requires the full delegation chain, referral resolution, and an answer to the question of who operates the levels above you. This is the hardest case and the least built.

Each enclave runs a complete, independent registry. Because the networks do not interconnect, there is no cross-registry reconciliation to solve — federation, the project's largest missing piece, is simply not required. Isolated networks are therefore an unusually good early fit, not a compromise.

Some top-level domains are sponsored and closed: a single organisation controls them, and names are assigned administratively rather than sold by competing registrars. Such a namespace is the strongest fit DNX has, for reasons that are structural rather than political.

• The authority already exists. DNX's hardest governance question — who decides who owns a name — is answered by an existing org chart.
• Squatting disappears. First-come-first-served is a real weakness on the open internet. In a namespace where every registrant is a known member, it is not a threat model.
• Ownership proof is already solved. No need to invent a mechanism for proving you control a name; the sponsor already knows.
• The hierarchy is already organisational. Closed namespaces tend to mirror real reporting structure, which is exactly the location-shaped tree the routing layer wants.

A sponsor need not be the only registry within its namespace. It can delegate whole branches to constituent organisations, exactly as closed TLDs already delegate today.

One authoritative registry per zone does not mean one server. The registry is a role, and any serious deployment replicates it — otherwise a single machine failure removes an entire branch of the namespace from the network.

The naming authority replicates easily: its data is slow-moving and every record is signed, so replicas need not be trusted, only checked. The location directory is harder, because heartbeats arrive continuously and endpoints change — replicas must either share live state or each maintain their own view.

What happens when a registry is unreachable is worth being precise about. Existing sessions keep working — once two peers have exchanged keys and punched a path, the registry is out of the loop entirely. What breaks is new resolution and new rendezvous. That is a meaningfully softer failure than a DNS outage, but it is still an outage.

Everything above from section 3 onward is design, not implementation. What exists today is a single registry process, on a single machine, authoritative for everything, run by one person. Specifically missing:

• Delegation and referral. Built A registry is authoritative for a zone and may delegate branches to others; a resolver follows signed referrals until it reaches an authoritative answer. Not yet running on the public network, which still has a single registry.
• Signed responses. Built Resolution answers and referrals are now signed, and a node given the registry's key refuses anything it cannot verify. This was previously the most serious gap on this page, for the reason that follows. A resolution answer carries the peer's public key as well as its endpoint, and the asking node has no independent knowledge of that key — so a forged answer can name a key the attacker holds, survive the handshake, and be reported as verified. Signing registry responses is therefore a prerequisite for federation, not an improvement to it: a forged referral in a delegated system is worse still.
• Replication. No failover, no anycast, no replicas.
• Metadata privacy. The single registry observes every resolution, and therefore knows who talks to whom. Delegation improves this by scoping each registry's view to its own zone, but does not eliminate it.
• Ownership binding. Nothing ties a DNX name to actual control of the corresponding domain, so any unclaimed name may currently be registered by anyone. Once claimed it cannot be taken — including while its owner is offline, or while the registry itself is restarting. It can be handed on deliberately with a transfer signed by the current key, or released by the registry operator when a key has been lost.

These are listed in the protocol's security section as well. A design note that described only the intended architecture, without saying how much of it is imaginary, would be marketing.