Why not just use something that already works?

What it does. DNS maps names to addresses; IP routes the addresses. It is the most successful naming system ever built, and it is not going anywhere.

Where DNX differs. DNS resolves; it does not forward. The moment a name becomes an address, the name stops mattering — which is why a host that moves is stale until a TTL expires, and why an address proves nothing about who answered. DNX keeps the name meaningful all the way down: routers forward on it, and the key bound to it makes the reply verifiable.

Where DNS wins. Universality, caching, decades of operational knowledge, and delegation that actually works at global scale. DNX's registry is a single server. DNS is a planetary system with governance. That is not a small gap.

What it does. A small, fast, audited VPN. Peers are identified by public keys; traffic is encrypted with modern cryptography and almost nothing else.

What DNX borrows. The identity model, frankly. "The keypair is the machine" is WireGuard's insight, and DNX's session layer uses the same primitives for the same reasons.

Where DNX differs. WireGuard has no naming and no routing story — you configure peers with keys and endpoints, and you assign IPs by hand. DNX generates names, resolves them, traverses NAT automatically, and forwards on the name hierarchy. WireGuard is a tunnel; DNX is trying to be an addressing layer.

Where WireGuard wins. Everything that matters for production: it is audited, in the Linux kernel, and enormously faster than a userspace prototype. If you need encrypted transport today, use WireGuard. There is no honest argument otherwise.

What they do. Managed overlay networks: a coordination server distributes keys and endpoints, NAT traversal is automatic, and machines get memorable names. If DNX's demo looks familiar to you, this is why.

Where DNX differs. These are flat meshes: a coordination server knows every node, and every node can be told about every other. That model is excellent and it does not aggregate — the coordinator's knowledge grows with the number of machines. DNX's claim is about hierarchy: a core router holds one entry per top-level domain regardless of how many hosts exist beneath it. Whether that matters depends entirely on whether you believe overlays should scale like the Internet or like a company network.

Where they win. Maturity, reliability, support, and the fact that they solve the problem people actually have.

What it does. A modular peer-to-peer networking stack — transports, multiplexing, peer identity from keys, DHT-based discovery. It is the plumbing under IPFS and many others.

Where DNX differs. libp2p peers are identified by a hash of their public key, which is unforgeable but unreadable and carries no structure. Discovery is a distributed hash table: flat, and unrelated to any hierarchy. DNX's identifiers are human hierarchies that a router can aggregate on. libp2p optimises for permissionless discovery; DNX optimises for structured routing.

Where libp2p wins. It is a real library you can build an application on this afternoon, with implementations in several languages and no central coordinator anywhere.

What they do. Anonymity networks. Onion addresses are self-certifying names derived from keys, which is a genuine parallel to DNX's binding of names to keys.

Where DNX differs. Tor deliberately destroys the relationship between a name and a location — that is the entire point. DNX deliberately preserves it, because it wants routers to aggregate on it. The two designs want opposite things.

Where Tor wins. If you need to hide who is talking to whom, DNX is the wrong tool and always will be. DNX conceals payloads, not relationships: the registry sees who resolves whom.

What it does. A clean-slate inter-domain architecture built around isolation domains and path-aware routing, where senders choose paths and trust roots are explicit. It is deployed in production networks, notably in the Swiss financial sector.

Where DNX differs. SCION reorganises routing between networks, keeping addresses roughly as they are. DNX reorganises the address itself and lets the hierarchy do the routing. They are attacking different halves of the same discomfort.

Where SCION wins. It is vastly more mature, has real deployments, formal analysis, and an actual answer to inter-domain trust. DNX has a prototype and a document.

What it does. The most serious existing attempt at name-based forwarding: routers hold name-based forwarding tables and route requests toward data rather than hosts. Research since roughly 2009.

Where DNX differs. NDN names content; DNX names endpoints. NDN is pull-based — you express interest in a name and data comes back — which changes the application model profoundly. DNX keeps ordinary host-to-host connections, which makes it far less ambitious and far easier to deploy incrementally.

Where NDN wins. Depth. NDN has years of published research on exactly the hard problem DNX hand-waves: making name-based forwarding tables fast enough for real hardware. DNX borrows from that literature rather than competing with it.

What it does. Forwards on a stack of short labels rather than addresses. Each hop reads the top label, swaps or pops it, and forwards — in hardware, at line rate, in essentially every large carrier network on Earth.

Why it matters here. This is the strongest evidence that DNX's forwarding model is implementable. "Variable-depth stack of small identifiers, each hop reading only the top one" describes MPLS and DNX equally well. The objection that name-based forwarding cannot run at line rate is answered by twenty years of production MPLS.

Where DNX differs. MPLS labels are locally significant and signalled per path — they mean nothing outside the router pair that agreed on them, and they carry no identity. DNX identifiers are derived from a namespace that means something everywhere, and are bound to keys. MPLS is a forwarding optimisation beneath IP; DNX is trying to replace what is being forwarded on.

What they do. All three split identity from location, which is the same instinct DNX has. ILNP separates identifier and locator within addressing; LISP tunnels between locators using a mapping system; HIP inserts a cryptographic host identity between the transport and network layers.

Where DNX differs. These keep locators numeric and add a mapping layer to reach them. DNX makes the locator a routable name hierarchy, so the thing you route on is the thing a human reads. HIP is the closest relative on identity; DNX's contribution is fusing that cryptographic identity to a locator that aggregates.

Where they win. They are standardised, analysed, and in LISP's case widely implemented. DNX should be read as a descendant of this family, not a rival to it.

Stripping away everything that already exists elsewhere, the claim reduces to one combination:

• A human-readable name hierarchy used directly as the routing hierarchy, so forwarding tables aggregate by construction rather than by allocation policy.
• A cryptographic identity fused into that same hierarchy, so reaching a name and verifying its owner are the same operation.
• An incremental deployment path over existing IP, so none of it requires a flag day.

Each ingredient exists somewhere already. The combination is what DNX is testing, and the honest position is that it is a hypothesis with a working prototype — not a finished argument.

If you think this is wrong, that is a useful thing to say out loud: github.com/Xbitium/DNX