DNS Is 40 Years Old and Still Running the Internet. Something Has to Change.

DNS was specified in 1983. The internet it was designed for had a few hundred hosts. The directory fit in a text file called HOSTS.TXT, maintained by a single organization and distributed manually.

That file became a protocol. The protocol became infrastructure. The infrastructure became, effectively, permanent.

Today DNS handles hundreds of billions of queries per day across every device, application, and service connected to the internet. It is the reason you can type a name and reach a machine. It is also a 40-year-old system designed for a world where one organization could reasonably know the name of every computer on the network.

That world ended around 1985.

What DNS actually does, and doesn't do

DNS resolves names to addresses. You ask for a name; it returns a number. That's the job.

The architecture that performs this job is hierarchical in shape but centralized in authority. At the top is a root zone, maintained by ICANN and served by 13 root server clusters. Below that are the TLD registries: Verisign for .com, various national registries for country codes. Below that are the authoritative nameservers for each domain, usually operated by whoever registered it or by a DNS hosting provider.

Resolution traverses this hierarchy top-down. A resolver asks the root where to find .com, asks the .com registry where to find example.com, asks example.com's nameserver for the actual record. The answer is cached for a period defined by the TTL, then discarded and refetched.

This works. It has worked, at scale, for four decades. The engineering is genuinely impressive.

It also has structural properties that were acceptable in 1983 and are now load-bearing constraints.

Names are static. A DNS record is a mapping: name points to address. The record can change, but change requires propagating a new record through the cache hierarchy, waiting for TTLs to expire, hoping resolvers respect them. The namespace does not evolve; it is updated.

Authority is fixed and hierarchical. The authority for a name is determined by who controls the zone containing it. You cannot hold authority for a name without controlling the zone. Zones are defined by the hierarchy. The hierarchy is defined by the root. There is no path to local authority that doesn't trace back to ICANN.

The system does not govern itself. DNS has no native mechanism for a segment of the namespace to define its own mutation policy, manage its own cache coordination, or make structural decisions about its own scope. Those decisions happen outside the protocol, through registrars and zone administrators, and propagate downward.

Why this matters now

For most of the web, DNS's limitations are invisible. You register a domain, point it at a server, it works. The TTL delay when you change records is annoying but manageable.

The constraints become structural in a few specific contexts.

Edge and distributed systems. A CDN or edge platform distributes execution globally but still resolves names through DNS. Naming authority remains central even when compute is not. The edge node closest to your user knows where to serve the request from, but it doesn't govern what the request's name means or when that meaning can change. That authority still lives upstream, in a zone controlled by a registrar or a platform's control plane.

Jurisdictional fragmentation. DNS has no native concept of a name that means different things in different jurisdictions, or a namespace segment that can implement region-specific policy without forking the zone. Jurisdictional variations are handled through application logic layered on top, not through the resolution architecture itself.

Dynamic and ephemeral resources. Microservices, serverless functions, AI agents, IoT devices: these are resources that are created, mutated, and retired at a rate that DNS's TTL-based consistency model was not designed for. Workarounds exist: low TTLs, service meshes, sidecar proxies. They all involve working around DNS rather than through it.

Identity and persistence. DNS names are owned, not identity-bearing. The name example.com has no structural relationship to what it names, no continuity through mutation, no provenance. If the registrar is seized, the domain transferred, or the TTL expired, the name means something different or nothing at all.

What replacing it actually requires

DNS has survived this long partly because it is genuinely good at its original job and partly because the cost of replacing foundational internet infrastructure is enormous. Every device, every application, every library has DNS resolution baked in. HTTPS depends on it. Email depends on it. The web depends on it.

Replacement doesn't mean ripping it out. It means building a resolution architecture with different structural properties that can coexist with DNS and eventually subsume the cases where DNS's constraints are the binding constraint.

The structural properties that matter:

Local authority. A segment of the namespace should be governable by the nodes responsible for that segment, under locally held policy. The authority for a name should be traceable to the scope that contains it, not to a hierarchy whose root is a single organization.

Governed mutation. Changes to a name's meaning, the structure of a namespace, or the validity of a cached mapping should be subject to a validation process defined by the governing scope. Not a TTL countdown and a zone file update. Mutation should be proposable, evaluable, and approvable through a defined process that produces an auditable lineage.

Structural adaptation. A segment of the namespace that grows beyond its governance capacity should be able to split into child scopes. A segment that becomes inactive should be able to merge. These structural decisions should be made by the nodes governing the segment, not by a zone administrator working outside the resolution protocol.

Alias continuity. A name should remain resolvable through structural changes. If the scope containing a name splits, the name should trace through the new structure. If a resource is relocated, the alias should redirect through the new scope. Continuity through mutation is a structural property, not a post-hoc redirect.

These four properties describe a resolution architecture that does not currently exist as deployed infrastructure. DNS does not have them. ENS and other blockchain-based naming systems are experiments with some of them, but introduce global ledger constraints that reproduce a different form of centralization. Existing service mesh and discovery solutions are scoped to private infrastructure and don't address global resolution.

The indexing layer

The structural approach that satisfies these properties is an adaptive, anchor-governed index: a hierarchical namespace where each segment is governed by the nodes responsible for it, mutations are validated through scoped consensus, resolution traverses the hierarchy stepwise through local anchor groups, and structural changes preserve lineage continuity.

This is not a routing protocol. It is an indexing and resolution layer that sits above transport, making names meaningful, governable, and persistent across the full lifecycle of the resources they identify.

The reason DNS has lasted 40 years is that it solved a genuinely hard coordination problem at a scale nobody had reached before. The reason something has to change is that the coordination problem has changed. The internet no longer has a few hundred hosts with stable addresses. It has billions of resources: ephemeral, distributed, jurisdictionally complex, AI-mediated. Their naming requirements are not what DNS was built for.

The replacement will not announce itself. It will appear as an indexing layer that handles the cases DNS cannot, coexist quietly with the cases DNS still handles fine, and expand from there.