DNX — Domain Native eXchange Category: Experimental Working draft · v0.1 · July 2026 dnxroute.com

203.0.113.7
computer1.internal.dnxroute.com

DNX is an experimental internet protocol where the name is the address. Machines register a fully-qualified domain bound to a cryptographic key. No visible IPs, no NAT configuration, no port forwarding — and every reply is signed by the machine that owns the name.

Recorded July 13, 2026 · 02:29 UTC

A cloud server pinged a laptop behind a home router. By name.

This is a replay of the actual session — real commands, real round-trip times. The target machine sits behind an ordinary residential NAT with zero configuration. The first reply includes the full NAT hole-punch negotiation; the second rides the established direct path.

xbitium@dnxroute1 — recorded session

rtt drops 396 → 49 ms because ping #1 pays for the hole punch; ping #2 is a direct peer-to-peer path.

Protocol flow

Resolve. Punch. Verify.

STEP 1 — RESOLVE

The living registry

Every node heartbeats to the registry, which binds each name to a (public key, live endpoint) pair — first-come, first-served. Records update in seconds, not TTL-hours.

STEP 2 — INTRO

NATs open themselves

The registry introduces the two nodes; each fires packets at the other, opening both NATs simultaneously. No port forwarding, no VPN, no router settings.

STEP 3 — VERIFY

Identity, not just reachability

Every reply is ed25519-signed by the key bound to the name. identity_verified=true means you reached the machine that owns the name — something ICMP never proved.

What changes

The numeric layer becomes invisible.

Today (TCP/IP + DNS + NAT)DNX
Machines are numbers: 10.0.0.14, 192.168.1.x Machines are names: computer1.internal.dnxroute.com
DNS records go stale for hours (TTL) Registry updates in seconds via signed heartbeats
Reaching a home machine: port forwarding, DDNS, VPN Reaching a home machine: dnx ping mymac.internal…
Ping proves an address answered Ping proves the name's owner answered (ed25519-signed)
Identity bolted on above the network (TLS, later) Identity native to the address layer itself
Registry log · first names bound

The birth certificate

From the registry's journal on launch night — the first names ever bound to keys on the DNX network.

dnx-registry up on :4400 — the name IS the address.
NEW name bound: dnxroute2.internal.dnxroute.com → key SXH3F777…
NEW name bound: dnxroute1.internal.dnxroute.com → key 2J7LLD+m…
NEW name bound: mymac.internal.dnxroute.com → key r5mqD5mO…
INTRO dnxroute1.internal.dnxroute.com → dnxroute2.internal.dnxroute.com
reply … rtt=2.53 ms identity_verified=true
Status

Built in the open, one layer at a time.

v0.1 LIVE

Living registry at registry.dnxroute.com · signed name→key binding · NAT hole punching · identity-verified ping. Proven across the public internet and a residential NAT.

v0.2 NEXT

Encrypted channels (X25519 + ChaCha20-Poly1305) and a reliable stream layer — so real applications ride DNX, ending with ssh into a NAT'd machine entirely over DNX.

v0.3 PLANNED

Relay fallback for symmetric NATs · dnx tunnel port gateway · federated registries with a signed name table.

Participate

Run a node. Claim a name.

DNX is an experiment in what addressing should feel like. The prototype is a single static binary — one command and your machine has a name on the network, bound to a key only it holds.

$ dnxd --name yourmachine.internal.dnxroute.com --registry registry.dnxroute.com:4400
$ dnx ping dnxroute1.internal.dnxroute.com