If I Had to Rebuild the Internet Today

The internet works astonishingly well for a system whose core assumptions were fixed before most of its users were born. Some of those assumptions have aged beautifully — the dumb network and the best-effort packet have survived every application their designers never imagined. Others we now paper over with three layers of workaround: security bolted on after the fact, identity grafted onto addresses, and trust delegated to a short list of companies that nobody chose. If I had to rebuild it today, I would keep the parts that are genuinely load-bearing and throw out the parts we only defend because changing them is harder than living with them.

Keep: the dumb network

Pushing intelligence to the endpoints is why the internet survived everything from email to streaming to whatever comes next. Routers forward packets; they do not interpret them. That stubborn refusal to know anything about the traffic it carries is the property that let the web, video, voice, gaming and a decade of startups ride the same wires without a protocol redesign. Any redesign that puts application semantics into routers dies the moment the next unexpected thing arrives, because routers are exactly the layer you cannot upgrade in a weekend.

The same goes for the best-effort contract. The internet does not guarantee delivery, ordering or latency; it agrees to try. That honesty is a feature. Congestion is a shared problem solved by the endpoints throttling, not by the network pretending it can reserve bandwidth it does not have. Every attempt to add quality-of-service guarantees at the core adds complexity that must be implemented in every router on the planet — a cost that makes the cure worse than the disease. Keep the network stupid. It is the closest thing to a law of nature that networking has.

Replace: identity bolted on afterwards

The original design conflated three things that should have been separate: what you are (identity), where you are (address), and how you are found (name). A device's IP address is a location, but it doubles as the closest thing the network has to identity — which breaks the moment a device moves, roams, or is shared behind NAT. Names were never cryptographically bound to anything; DNS entries are assertions made by whoever controls the zone file. And trust, layered on top, was delegated to a certificate authority list that nobody audits and that a single compromise can turn into global impersonation.

• Addresses double as identity, which breaks the moment a device moves.
• Authentication of routes is optional, so route hijacking stays trivial.
• Trust is delegated to a certificate authority list nobody audits.

The consequence is a security model assembled from band-aids: TLS for the last hop, DNSSEC mostly unwired, and a routing protocol that still accepts announcements from anyone who asks. BGP hijacking remains practical decades after it was first demonstrated, because authenticating routes was designed in as an afterthought. The day a Kazakhstan network hijacked the DNS root server prefixes, and the day a couple of Brazilian networks blackholed Cloudflare's resolver, both happened for the same reason: nothing in the core verifies that the route being announced is one the announcer is entitled to use.

What I would actually do

Cryptographic identity at the naming layer: every name bound to a public key, so that what you resolve to is what you meant. Addresses as pure locators: an IP becomes just a postal code for a point of attachment, free to change without changing who you are. And authenticated routing as a requirement rather than an upgrade: route announcements carry origin and path validation by default, with the half-hearted RPKI adoption of today promoted to a baseline that every network must enforce to participate. None of these is speculative — every piece has been standardised, shipped, and proven in isolation. The failure is integration, not invention.

This is the part where redesigners usually get lost in elegance. Names bound to keys would subsume certificates entirely — no separate CA hierarchy, because the key the name points to is the trust anchor. Addresses as pure locators would let a laptop carry its identity across networks the way a SIM card carries a phone number. Authenticated routing would make the June 2025 root-server hijack impossible rather than merely rare. All of it is beautiful. All of it is also a migration that would take decades and fight every entrenched interest in the existing system — which is precisely why the honest design includes the migration, not just the destination.

The migration is the real design constraint

Here is where the thought experiment collides with reality. A protocol change only matters if everyone adopts it, and the internet's reward structure punishes early adopters: you pay the cost of running both worlds while the benefit only materialises once the long tail follows. IPv6 has been the protocol of the future for twenty-five years. DNSSEC still carries training wheels. The lessons from those migrations are brutal — incremental deployment on a network that cannot be switched off, and economic incentives that actively discourage being first.

So I would not demand a big-bang rewrite. I would do what the last fifty years have actually shown works: keep the dumb network, and pour the new security into layers that can be deployed one hop at a time. Authenticated routing one autonomous system at a time. Names with keys, resolvable from ordinary clients behind an optional header. Addresses decoupled from identity behind the existing NAT-and-anycast machinery. Each increment must work for someone who has installed nothing and made no change — that is the only migration the internet has ever accepted.

The transport layer barely needs to change

The one part of the stack that genuinely aged well is the transport. TCP got its retransmissions, congestion control and reliability right, and every improvement since — faster handshakes, better loss recovery, encryption integrated into the transport with QUIC and TLS 1.3 — has been an incremental upgrade to the same foundation rather than a replacement. If I were rebuilding, I would keep that foundation and resist the temptation to redesign it. The lesson of the last decade is that transport improvements succeed when they ship in user-space and prove themselves one connection at a time, which is exactly why the modern stack looks like today's internet rather than a committee's dream protocol.

That is the deeper point underneath the whole thought experiment. The internet is a system that cannot be switched off, so its future is always negotiated through compatible increments, not clean slates. Any honest answer to 'how would I rebuild it' has to respect that constraint. The design that wins is not the most elegant one on the whiteboard; it is the one that delivers immediate value to someone who changes nothing about how they use the network. Keep the dumb network, keep the reliable transport, harden the layers that bolt security and identity on top — and accept that the rebuild is a process, not a moment.

Every legacy system is a working system that outlived the argument against it.

And that is precisely why we still have the internet we have. It works. A redesign that cannot demonstrate day-one value to someone who changes nothing is a redesign that will never happen. The honest engineering answer is not to rebuild the internet — it is to keep the parts that are load-bearing, and to keep paying down the debt in places where the payoff can be proven incrementally: route origin validation, better certificates, names that carry keys. Fifty years of hindsight does not buy you a clean slate. It buys you the wisdom to stop pretending you are going to get one.