DNXRoute
Domain Native eXchange

Experimental networking protocol

The domain is the network.

Names, not numbers. Identity, not assumptions. Built on today's Internet. Designed for tomorrow's.

DNX is an experimental protocol in which your namespace hierarchy becomes the routing topology — routers forward on names, and every reply is verifiable against the key that owns that name.

Read the protocol Try the playground Watch it route, live

How DNX works

A name becomes a route.

Today a name is a lookup key: DNS turns it into an address, and the address does the real work. DNX removes that translation step. The name is the routing information, and the key bound to it is the proof of who answered.

YOU TYPE host1.dnx .dnxroute.com REGISTRY RESOLVES registry seconds-fresh, signed YOU GET BACK ed25519 key who owns the name locator path how to route toward it live endpoint where it is right now No IP is ever typed, configured, or displayed. It still exists underneath — see the stack below.
Resolution returns three things, not one. DNS gives you an address; DNX gives you an address, an identity, and a route.
  1. Register. A node generates an ed25519 keypair on first boot and binds it to a fully-qualified domain at the registry. The key is the machine; the name is its handle. First key to claim a name owns it.
  2. Resolve. Asking for a name returns its public key, its routing locator, and its live endpoint — refreshed by heartbeat every 15 seconds, not cached for hours.
  3. Rendezvous. The registry introduces the two nodes so both fire packets outward at the same moment, opening each NAT from the inside. No port forwarding, no VPN, no router configuration.
  4. Handshake. An X25519 exchange, signed by the ed25519 identity the registry bound to the name. The session key is therefore provably owned by whoever owns the name — and it is discarded every five minutes.
  5. Route. Packets are forwarded hop by hop on the name hierarchy itself. Each router reads exactly one level and passes it on; none reads the whole name, and none can read the payload.

Architecture

Where DNX sits.

DNX is an overlay, deliberately. It runs on UDP/IP today for the same reason IP first ran over the phone network: the on-ramp matters more than the purity. Everything above the substrate line is DNX's own.

Application ssh · http · anything that speaks TCP unmodified DNX Stream sequencing · ACKs · retransmit · flow control v0.2 DNX Session X25519 handshake · ChaCha20-Poly1305 · 5-min rekey v0.2 DNX Locator forwarding on the name hierarchy · aggregation v0.3 UDP / IP today's Internet — the substrate borrowed D N X Each layer knows only the one beneath it. Swap the substrate later without touching the layers above.
The honest picture: DNX owns identity, encryption, reliability and routing. It borrows packet delivery from IP — for now.

Routing

Each hop reads one level.

This is the part that has to scale, and the reason it can: a router never reads a whole name. It reads the single level it is responsible for, forwards, and forgets the rest. A core router therefore holds one entry per top-level domain — not one per host.

THE DESTINATION, LEVEL BY LEVEL .com top level dnxroute domain dnx subdomain host1 host core reads the top level only domain gateway reads the domain only site router reads the subdomain only leaf switch delivers to the host The core's entire forwarding table is one entry per top-level domain. Add a million hosts under dnxroute.com and that table does not grow by a single line. This is what makes it scale.
Aggregation is not an optimisation — it is the load-bearing wall. IP gets it from numeric prefixes; DNX gets it from the name tree.
Try it yourself

A packet routing across two datacenters, hop by hop, purely by name — with the real forwarding trace streamed back live from both machines: routing.dnxroute.com

The registry

So who controls the names?

This is the first question worth asking about DNX, and the honest answer today is uncomfortable: one server, run by one person. That is a prototype's answer, not an architecture's, and it is the largest unbuilt part of the design.

What the architecture intends is the same thing DNS already does — delegation. The unit of authority is a zone, and whoever operates a name runs the registry for everything beneath it. A company runs its own for its own namespace, inside its own network if it prefers, and nobody outside needs to know it exists.

.com registry delegates, stores nothing else dnxroute.com authoritative for its own branch yourcompany.com runs its own, privately host1.dnx.dnxroute.com laptop.eng.yourcompany.com Nobody runs "the" registry — each operator runs their own branch, exactly as DNS delegates today.
The same hierarchy does three jobs at once: it routes packets, it delegates authority, and it decides who may name what. That is not a coincidence — it falls out of using the namespace as the topology.

What a registry actually does

Three jobs are currently bundled into one service, and they have nothing in common. Naming authority answers who owns a name and changes almost never. Location directory answers where that name is right now and changes constantly. Rendezvous introduces two peers so they can punch through NAT, and holds nothing at all.

Separating them is most of the deployment story, because they want completely different trust, scale and caching.

Honest gaps

  • No delegation between registries yet — there is only one.
  • Registry replies are unsigned, so an on-path attacker can forge resolution answers.
  • No replication, so it is a single point of failure.
  • It observes every resolution, and therefore knows who talks to whom.

Read the full design note →

Status

What actually runs today.

DNX is an experiment, not a product. Below is the honest split between what is implemented and deployed, and what is still specification.

CapabilityStateNotes
Name → key registryLiveFirst-come-first-served binding, signed heartbeats, seconds-fresh records
NAT traversalLiveProven cloud → residential NAT with zero router configuration
Encrypted sessionsLiveX25519 + ChaCha20-Poly1305, forward secrecy on a 5-minute rekey
Name-hierarchical routingLiveDistributed routers across two datacenters, forwarding by name level
Reliable streamsBuiltSequencing, ACKs, retransmit, flow control — tested, not yet deployed
TCP tunnellingBuiltReal HTTP carried over DNX in the lab; deployment pending
Signed registry repliesPlannedA known gap — see the protocol's security section
Registry federationPlannedToday the registry is a single point of failure and of control
Do not deploy this in production

DNX is a research prototype with documented weaknesses, an unaudited implementation, and a wire format that will change. It is published so the design can be argued with, not so it can be relied upon.

Why DNX exists

The Internet is full of workarounds.

Almost every layer we bolt onto networking exists to recover something the network itself does not know. NAT exists because addresses ran out. VPNs exist because NAT broke reachability. TLS exists because an address proves nothing about who answered. DNS exists because numbers are unusable by people.

Each of these works. Together they mean a modern connection is a stack of compensations, and the network still cannot answer the simplest question: who is this?

DNX asks what happens if identity lives at the addressing layer instead of above it.

What that changes

  • A reply proves the name's owner answered — not merely that an address responded.
  • A machine behind a home router is as reachable as a datacenter server, with no configuration.
  • Records go stale in seconds, not TTL hours.
  • Moving a host does not invalidate the routes above it.

Read next

Go deeper.

The protocol

Wire format, identity model, forwarding algorithm, and a security section that lists its own weaknesses.

Why not DNS, WireGuard, or libp2p?

Honest comparisons, including the cases where the existing tool is simply the better answer.

Engineering journal

Design decisions and the bugs behind them — including a routing loop and a deadlock caught before they shipped.

Design notes go deeper on single questions: how the registry works and how it would federate. Changes still being argued live in proposals.