Paul Mockapetris: The Inventor Who Gave the Internet a Name

# Paul Mockapetris: The Inventor Who Gave the Internet a Name

Most people meet the Internet through a word. They type a domain into a browser, follow a link, read an email address, or recognize a company from the name printed on a screen. Underneath that familiar experience is a system that quietly translates human language into the numerical addresses computers use to communicate.

That system is the Domain Name System, usually called DNS. Its principal inventor is Paul V. Mockapetris, an American computer scientist and Internet pioneer who designed the architecture in the early 1980s while working at the USC Information Sciences Institute. In 1983, he described the concepts and facilities of the system in RFC 882 and its implementation in RFC 883. He then built the first working server implementation and helped deploy the early service at ISI and SRI. [1] [2] [3]

!Paul Mockapetris, DNS inventor, during a 2003 interview

*Paul Mockapetris during a December 12, 2003 interview. Photograph by Andreu Veà, WiWiW.org; used under CC BY-SA 3.0.*

Mockapetris did not invent the idea of a name in isolation. The early ARPANET already needed a way to associate host names with numerical network addresses, and many researchers contributed to the network’s evolution. His historic contribution was to replace a centrally maintained, increasingly fragile list with a distributed naming architecture that could be delegated, cached, replicated and extended. That design turned names into a durable layer of Internet infrastructure.

This is the story of the problem he inherited, the architecture he proposed, the engineering decisions that made it scale, and the reason domain names still matter to founders, operators, researchers and every person who uses the Internet today.

A browser user rarely thinks about the first question in a web request. Before a page can load, a machine usually needs to answer a basic problem: where is the service for this name?

Humans prefer memorable labels. A name such as pdomain.bond can be spoken, printed, recognized and associated with an organization. Network protocols, however, route traffic using numerical addresses. The machine needs an address such as an IPv4 address or an IPv6 address, and it may need other information about mail delivery, service discovery, authentication or policy.

A naming system connects those two worlds. It must accept changes without requiring every user to download a new global list. It must keep working when individual servers or network paths fail. It must allow different organizations to manage different parts of the namespace. It must support more than one kind of information, because a modern network name may identify a web service, mail exchanger, cryptographic policy, verification record or other resource.

Those requirements sound obvious now because DNS made them familiar. In the early 1980s, they were not a complete blueprint. The design had to be invented, debated, implemented and persuaded into use.

The ARPANET’s early naming method depended on a file commonly known as HOSTS.TXT. It contained mappings between human-readable host names and network addresses. The file was centrally managed by the Stanford Research Institute, often referred to as SRI in the historical accounts of the ARPANET. When a machine joined the network or changed its address, an administrator had to update the master information and distribute a newer copy to participating hosts.

For a small research network, this was workable. The number of machines was limited, the community was relatively close and the cost of manual coordination was manageable. The file also had an important virtue: it was simple. Everyone had the same list, and a local machine could answer a name lookup without contacting another server.

The weakness was structural. Every new host increased the size of the shared table. Every change created coordination work. Each participating site needed a current copy, and the process depended on a central administrative operation. As the ARPANET moved toward a broader TCP/IP-based Internet, the old method became a bottleneck rather than a foundation.

The issue was not merely that the file might become large. A global list placed too many responsibilities in one place. A central operator had to receive updates, decide how to record them and distribute the result. Users had no natural way to manage a part of the namespace themselves. The model offered one directory when the future required many cooperating directories.

Internet Hall of Fame describes the old arrangement as a single table on a single host and explains that Mockapetris responded with a distributed, dynamic naming system. [2] ACM’s account adds an important operational detail: the centrally managed file was manually updated and distributed to Internet sites on a daily basis. [3] The replacement therefore needed to solve both scale and administration.

Mockapetris joined ISI in 1978 as a graduate student from the University of California, Irvine. In his own account published by ISI, he describes a research environment where computers were plentiful and core network questions were still open. His group was supervised by Jon Postel, a central figure in the early Internet’s coordination and standards work. [1]

This context matters. DNS was not designed as a consumer product in a mature commercial market. It was developed while researchers were rethinking how a growing network should operate. The transition from the ARPANET to the TCP/IP Internet created an opportunity to question assumptions that had been acceptable when the network was smaller.

Postel asked Mockapetris whether he would work on the domain naming problem. The assignment was not simply to choose a prettier syntax for host names. It was to define how naming information should be organized, queried, updated and shared across an expanding network.

Mockapetris brought relevant experience. ICANN’s biography records dual bachelor’s degrees in physics and electrical engineering from MIT and a Ph.D. in information and computer science from UC Irvine. It also describes his earlier work on distributed systems and local-area network technology, as well as his later roles in Internet engineering and networking companies. [4]

The domain naming problem therefore sat at the intersection of theory and operations. It required a data model, a query protocol, server behavior, failure handling and a social model for delegation. A design could be elegant on paper and still fail if nobody could implement it or if organizations could not operate their assigned pieces.

The decisive idea was to treat the namespace as a distributed database rather than one file copied everywhere. RFC 882 describes a tree-structured domain name space. Each node or leaf identifies a set of information, and queries ask for a particular type of resource information associated with a domain name. [5]

The tree structure creates hierarchy. A name can contain a specific label and belong to broader domains above it. That hierarchy makes delegation possible. An authority does not need to know every name in existence. It can manage a zone and refer requests for other parts of the tree to the appropriate servers.

This is a different way to think about a directory. In a single-table model, every participant expects the same complete answer file. In a distributed model, an organization can be authoritative for one part of the tree while relying on referrals, caching and other authorities for the rest. The system remains one namespace from the user’s point of view even though its data is managed by many parties.

RFC 882 separates three important components: the domain name space, name servers and resolvers. A name server holds information about a part of the tree. A resolver extracts information from name servers in response to user requests. The namespace provides a consistent conceptual structure across those components. [5]

That separation is one of the reasons DNS survived. Users and applications do not need to know which authoritative server stores a record. A resolver can pursue the query. A name server can answer for its zone. Administrators can update their own data without editing a global file.

It is tempting to describe DNS as a phone book for websites. The analogy is useful for a first explanation, but it is incomplete. The original design was intentionally more general than a one-to-one mapping between a host name and an address.

RFC 882 states that domain names are not required to correspond one-to-one with host names, host addresses or any other single type of information. A query identifies the name and asks for a type of resource information. [5] This generality created room for the record types that later became essential to Internet operations.

An A record can associate a name with an IPv4 address. An AAAA record serves IPv6 addresses. MX records identify mail exchange services. NS records identify name servers. CNAME records provide aliases. TXT records can carry verification and policy information. SOA records describe zone authority and timing parameters. Modern DNS includes many additional uses and extensions.

The design did not have to predict every future application. It established a way to ask for typed information within a hierarchical namespace. That is a powerful pattern for infrastructure: define the stable boundaries and query behavior, then let later operators add useful data types without discarding the original architecture.

For a domain owner today, this means the name is connected to much more than a homepage. Email delivery, certificate validation, cloud service verification, security policy and application routing may all depend on DNS records. The visible name is only the surface of a distributed control plane.

In November 1983, RFC 882 documented the conceptual model of the domain name system. RFC Editor identifies Paul Mockapetris as the author and records that the document introduced domain names, their use for ARPA Internet mail and host address support, and the protocol and servers used to provide the service. [5]

The specification’s tree is more than a visual metaphor. Every node has a label, and the domain name represents a path from the root to that node. Printed labels are separated by dots. The root is conceptually present even though users normally do not type the final root dot.

The hierarchy makes containment testable. A domain is a portion of the tree at or below a name. A subdomain is contained within another domain. This lets the system reason about zones and authority without requiring a single operator to own the entire namespace.

RFC 882 also defines the idea of a zone. A name server can have complete information about a subset of the domain space. That subset is the server’s zone, and the server is authoritative for it. The same server can maintain more than one zone and can hold cached information about other parts of the tree.

This distinction between authoritative information and cached information is central to how DNS works. An authoritative server is responsible for the data it publishes for its zone. A resolver may hold a temporary copy of an answer to reduce latency and load. The cached copy must eventually expire so that changes can propagate.

The document specifies time-to-live behavior for cached records. A resolver remembers the TTL associated with returned resource records and discards the record when the permitted time has passed. [5] TTL is therefore not a random technical number; it is part of the balance between speed, resilience and the time required for changes to become visible.

RFC 883, also published in November 1983, moved from concepts into implementation. Its opening describes the purpose directly: it discusses the implementation of domain name servers and resolvers, specifies transaction formats and explains the use of domain names in mail and other network software. [6]

The separation between RFC 882 and RFC 883 shows a useful engineering discipline. A system needs a conceptual model that people can reason about, and it needs an operational specification that implementers can use. The two documents explain what the service is and how its components communicate.

RFC 883 describes recursive service as an optional capability. A server can answer from its own zones, or it can pursue a query for a requester and return the eventual result. The resolver algorithms also describe caching, choosing among available servers, retrying failures and following referrals to a closer name server. [6]

These are the behaviors that make a distributed system usable. A resolver does not need one perfect server. It needs a path through the namespace, alternate choices when a server does not respond and rules for deciding whether cached data is still valid.

The documents were later replaced by RFC 1034 and RFC 1035, which became the better-known conceptual and implementation references for DNS. That evolution does not diminish the importance of RFC 882 and RFC 883. The original documents captured the architecture that later specifications refined.

A specification becomes infrastructure only when it runs. ACM credits Mockapetris with developing the first DNS server implementation, called Jeeves, and deploying it at ISI and SRI for the initial root servers. The ACM citation describes those components together as the first stable operational DNS system. [3]

The implementation work exposed practical issues that a conceptual design could hide. A server needs data structures, transaction handling, timeouts, zone loading, caching behavior and responses to malformed or incomplete requests. It must operate on real machines and real networks, where packets can be delayed, duplicated or lost.

ISI’s historical account says that the first DNS server was launched in 1984 on the eleventh floor of ISI, followed by additional name servers at places such as SRI. Mockapetris was supported by Ruth Brungardt and later Steve Hotz, who worked on supporting utilities and test suites. [1]

That detail is important because infrastructure is rarely the work of one person alone. Mockapetris is correctly recognized as the inventor of the DNS architecture, but the first operational system depended on implementation support, testing and deployment by a wider community.

The early system also needed adoption. ISI researchers gave tutorials and helped other groups implement DNS for different computer systems. A protocol becomes a standard when others can understand it, build it and operate it. The work of explanation was therefore part of the invention’s practical success.

One of the most influential later implementations was BIND, the Berkeley Internet Name Domain software package. ISI describes BIND as a famous implementation created at UC Berkeley that helped computers participate in DNS. Its inclusion in Berkeley’s free version of UNIX helped spread the system through academic and wider technical communities. [1]

This is a recurring pattern in Internet history. A foundational protocol may begin with a small research implementation, but adoption accelerates when a reliable implementation becomes available on a widely used operating system. BIND gave administrators a practical path to operate DNS without writing their own server from the RFCs.

The adoption story also shows why architecture and implementation must be evaluated separately. Mockapetris designed the naming model and initial server. Others expanded, maintained and distributed implementations. The broader ecosystem grew through interoperability rather than through one vendor controlling every deployment.

For domain owners, this history explains why DNS feels both universal and decentralized. A browser may use a resolver supplied by an access provider, a public resolver or a local network. Authoritative data may be hosted by a registrar, a cloud provider, an independent DNS company or an organization’s own infrastructure. The same protocol connects those choices.

By 1986, operating systems and machines were being built that relied on DNS instead of the old host tables. Mockapetris says that this was when he knew the system had become production. [1]

Production status is more meaningful than a launch date. A design becomes production infrastructure when other systems assume it will be available, when operators depend on its behavior and when replacing it would create real disruption. DNS crossed that threshold because it was no longer merely an experiment at ISI. It was becoming the naming layer of a growing Internet.

The transition also changed the relationship between research and operations. ARPA decided in 1986 that DNS was no longer breakthrough research and funding shifted. Mockapetris moved into other work, including a program manager role at ARPA, while Postel and ISI continued operating part of the expanding root infrastructure and handling domain and Internet number allocation. [1]

A technology’s success can therefore create a strange moment for its inventor. The system becomes more important at the same time that the original research project ends. DNS moved from a defined experiment to a shared public utility.

Consider what happens when a user asks for a domain’s address. The application normally calls a resolver rather than contacting the global root directly. The resolver checks its cache. If a valid cached answer exists, the response can be returned quickly.

If the answer is not cached, the resolver needs to find an authoritative path. It can ask a server that knows the relevant part of the tree. The root system can point toward the appropriate top-level domain servers. Those servers can point toward the authoritative servers for the registered domain. The authoritative server can return the record for the requested name.

The exact operational path varies because recursive resolvers, caches, server policies and modern infrastructure introduce additional layers. The conceptual pattern remains the same: start with a name, follow the hierarchy, ask servers responsible for increasingly specific parts of the namespace and cache answers for a defined period.

This architecture avoids two opposite failures. It avoids making every resolver store every record permanently, and it avoids requiring one central service to answer every query. Data is distributed by authority, while repeated answers can be reused through caching.

The result is not perfectly centralized or perfectly peer-to-peer. It is a delegated hierarchy with redundancy, referrals and caching. That middle path is one of DNS’s most important design achievements.

Early network protocols often handled reliability by retransmitting a request until an acknowledgement arrived. DNS used a different approach for name service. ISI’s history explains that the design required multiple servers for a particular piece of data and allowed a requester to move to another server when one did not answer. [1]

A name service must be available before many other services can be reached. If the only server for a domain fails, users may be unable to locate the web server, mail server or other resource even when those systems are healthy. Multiple authoritative servers reduce that single point of failure.

Redundancy is not the same as duplication without rules. Servers need coordinated zone data, clear authority and timing. Resolvers need failure handling and cache behavior. Operators need to monitor servers and renew the domain’s delegation correctly.

For a modern business, this is why DNS configuration deserves operational care. A domain can appear registered while its nameservers are wrong, one of its authoritative servers is unreachable or its records do not match the deployed service. The domain name is a business identity, but the DNS layer is a distributed technical system that needs ownership and maintenance.

Mockapetris says that he did not anticipate domain names becoming equivalent to stock certificates or real estate deeds representing billions in value. [1] That observation captures the distance between the original engineering problem and the modern domain industry.

The original system made a name resolvable. Businesses later made names valuable through brands, customer memory, marketing, email, search, investment and legal protection. A domain can now be a company’s primary address, a product identity, a defensive registration, a campaign destination or an asset held for a future buyer.

This commercial value is not contained in the DNS protocol itself. DNS does not decide whether a word is memorable, whether a name fits a category or whether a buyer will pay a premium. It provides the stable namespace in which those decisions can operate.

That distinction matters. A domain name can be technically available and commercially wrong. It can be strategically valuable and operationally misconfigured. It can have a strong brand story but poor renewal economics. Domain ownership requires both naming judgment and infrastructure discipline.

The modern domain marketplace exists because a distributed naming system created scarce, recognizable digital addresses. Registries and registrars added commercial processes for registration, renewal and transfer. Businesses built websites, email systems and products around those addresses. The economic layer grew on top of the technical layer.

The first RFCs were revised as DNS matured. ACM notes that Mockapetris revised the specification in RFC 1034 and RFC 1035 in 1987 and broadened its scope with RFC 1101 in 1989. [3] Later engineers and standards groups continued adding record types, security features, internationalization support, operational guidance and new applications.

This is not evidence that the original design was incomplete in a negative sense. Internet infrastructure is expected to evolve. The original architecture provided stable concepts that could be extended without replacing the whole namespace.

DNSSEC introduced cryptographic mechanisms for validating DNS data. Internationalized domain names allowed labels to represent languages beyond the original ASCII-oriented environment through defined encoding processes. Service records supported application discovery. Text records became useful for verification and policy. Reverse DNS created a corresponding address-to-name space for operational purposes.

Each extension creates new implementation and governance questions. More capability can mean more complexity. Yet the continued use of the same core architecture shows the value of a design that separates names, data types, authority, transport and resolution behavior.

DNS became one of the original Internet standards after the formal creation of the IETF in 1986, according to Internet Hall of Fame and ICANN biographies. [2] [4] Mockapetris was associated with the IETF from its creation, chaired working groups and served as IETF chair from 1994 to 1996. [4]

Standards organizations matter because a distributed network cannot depend on one laboratory’s private implementation. Different operators need shared expectations about names, messages, errors, caching and authority. The standards process makes it possible for systems built by different groups to interoperate.

The IETF tradition also recognizes that protocols are living documents. Implementers discover edge cases. Operators report failure modes. Security researchers identify weaknesses. New applications require new record types or constraints. The protocol evolves through technical documents, discussion and deployed experience.

Mockapetris’s role therefore extends beyond the original invention. He helped establish a naming system that could participate in an open standards culture rather than remain a proprietary service.

The domain name system was the most famous part of Mockapetris’s career, but it was not the only part. Internet Hall of Fame describes his work in research and industry, including contributions connected to distributed systems, local-area networking and later networking companies. It records leadership roles at @Home, Software.com, Fiberlane and Siara. [2]

ICANN records that he served as a networking program manager at ARPA in the early 1990s and supervised efforts including gigabit and optical networking. [4] That role reflects a broader pattern in his work: focus on the infrastructure that allows systems to communicate, scale and remain useful as demand changes.

ACM named Mockapetris an ACM Fellow in 2004 for contributions to the Internet, including domain and email protocols, and later recognized him with the 2019 ACM Software System Award for developing DNS. [3]

The recognition is significant because the award is for a software system, not simply a theoretical paper. DNS combined a specification, query protocol, server implementation and early deployment into a functioning service. The innovation was architectural and operational at once.

The Internet Hall of Fame inducted Mockapetris in 2012 and describes DNS as the invention that expanded the Internet beyond its academic origins. [2] ACM’s citation emphasizes that DNS provides a worldwide distributed directory service and remains an essential component of the global Internet. [3]

Those descriptions highlight different aspects of the same achievement. The Hall of Fame focuses on accessibility: recognizable names made the Internet easier for people and organizations beyond the original research community. ACM focuses on systems engineering: a distributed directory continued to work as the network expanded.

A domain name is often treated as a marketing asset because that is how most users encounter it. The awards remind us that the name sits on top of an infrastructure invention. The brand is visible; the distributed directory underneath is easy to forget precisely because it usually works.

When Mockapetris first designed DNS, the system handled only a few thousand name lookups per day, according to ACM’s award description. ACM’s later account says the same core components now support hundreds of millions of separately managed domains and tens of billions of queries each day. [3]

Exact counts change over time and depend on how domains and queries are measured. The important point is the scale difference. DNS was designed when the network was tiny compared with today’s Internet, yet the architecture remained recognizable through enormous growth.

The system’s survival does not mean every DNS component is unchanged. Root server operations, anycast deployment, resolver software, authoritative hosting, transport options and security practices have all evolved. What persisted is the logic of delegation, authority, resolution, caching and typed records.

Good infrastructure creates room for future scale without requiring the original inventor to predict every use. That is the deeper lesson of DNS: design stable boundaries and clear interactions, then let an ecosystem extend the system.

Users rarely type a root name server address, but the root of the hierarchy anchors the namespace. It provides information that helps resolvers find the authoritative servers for top-level domains. From there, the query can move toward the registered domain and the relevant host or service record.

The root is not a giant list of every web address. That misconception can make DNS sound more centralized than it is. The root provides referrals for the top level of the hierarchy. Authority for specific zones is delegated downward.

This arrangement supports independent management while preserving a coherent namespace. A country-code registry can manage its portion. A generic top-level domain registry can manage another. A domain owner can manage its own zone through authoritative nameservers. Each level has a role and a boundary.

The root system is nevertheless critical. Errors or attacks at higher levels can affect large groups of names. That is why root operations, delegation data, registry policy and DNS security receive so much technical and institutional attention.

A domain name is a namespace identity. A website is one service that may use that identity. The distinction is practical.

A domain can route web traffic to a hosting platform, send email through a separate provider, verify ownership with a third-party service and publish security policy through different DNS records. It can contain many subdomains, each with different infrastructure and owners.

A company that buys a premium domain is therefore acquiring an address with optionality. It can become a homepage, product surface, email identity, campaign system or defensive asset. The value comes from the name’s fit and the future uses that can be attached to it.

At the same time, a domain acquisition should include operational due diligence. The owner must secure registrar access, preserve DNS records, verify transfer control, configure email authentication and document the systems that depend on the name. A premium name with weak control can become a premium target.

This is one reason domain strategy is not only branding. It sits between language, technology, governance and business continuity.

The first lesson is to solve the scaling problem, not only the immediate problem. The old host table worked for a small network. It became dangerous when growth turned manual coordination into a bottleneck. A company’s naming system can experience the same transition. A single founder’s memory may work at the beginning; a growing portfolio needs a register, ownership rules and renewal decisions.

The second lesson is to separate authority from access. DNS lets each organization manage its zone while users can access information across the whole namespace. A company should similarly make ownership clear without preventing the right teams from operating services.

The third lesson is to design for failure. Multiple servers, retries, referrals and cache expiration were not decorative features. They reflected the reality that networks fail. A domain strategy should include recovery contacts, transfer locks, DNS backups, email continuity and rollback plans.

The fourth lesson is to leave room for new uses. Mockapetris did not design DNS only for one web page. The typed resource model supported mail, service discovery, verification and later extensions. A strong brand domain should have enough clarity and flexibility to support a company as its products change.

The fifth lesson is that naming creates infrastructure. A good name is not only memorable. It becomes the address in documentation, invoices, email signatures, applications, social profiles and customer conversations. Changing it later can be expensive because the name has accumulated relationships.

A domain marketplace can easily become a catalog of short strings and prices. History adds context. The domain name system was created to make a growing network legible and manageable. Every domain purchase now participates in that naming layer.

Understanding the inventor’s work changes how a buyer evaluates a name. The buyer is not only asking whether a word sounds good. The buyer is deciding whether the name can carry a stable identity across systems and time.

A strong domain should be easy to say, type, remember and delegate. It should work in a browser and an inbox. It should fit a product without trapping the company in a narrow promise. It should be secure to transfer and economical to renew. These are modern business questions built on top of Mockapetris’s original infrastructure.

The marketplace should also preserve the distinction between technical availability and commercial value. DNS can tell us whether a name resolves. It cannot tell us whether customers will trust it, whether a company can defend it or whether the price is rational. Those judgments require research, category knowledge and a clear acquisition thesis.

The portrait used with this article comes from Wikimedia Commons. It records Paul Mockapetris during a personal interview to record his voice on December 12, 2003. The photograph was created by Andreu Veà of WiWiW.org and is published under the Creative Commons Attribution-ShareAlike 3.0 Unported license. [7]

The image is useful because it connects a technical invention to a person rather than presenting DNS as an abstract acronym. The system may now answer billions of queries, but it began with researchers asking how a growing network could use names without collapsing under its own administrative weight.

The photo also reminds us that infrastructure history is built by people working across decades. The final system may look inevitable when viewed from a browser in 2026. It was not inevitable in 1983. The hierarchy, delegation, caching and redundancy had to be chosen, specified and made operational.

DNS solved the naming problem, but naming is never permanently solved. New top-level domains, internationalized names, privacy requirements, security threats, censorship concerns, name collisions and automated certificates continue to create operational questions.

The system’s success can make its risks less visible. A domain can be hijacked through a compromised registrar account. A DNS record can be changed accidentally. A low TTL can increase traffic to authoritative servers. A high TTL can delay a migration. A forgotten subdomain can expose an old service. DNSSEC can be misconfigured. Email can fail even when the website is online.

The correct response is not to abandon the architecture. It is to operate it with the same care that made it valuable. The system remains a shared layer, so its security and reliability depend on registries, registrars, authoritative operators, recursive resolvers, application teams and domain owners.

Mockapetris’s own work is a reminder that foundational infrastructure needs both simplicity and discipline. The concepts should be understandable. The operations should be documented. The failure paths should be expected. The ecosystem should be able to extend the system without destroying interoperability.

Paul Mockapetris gave the Internet a way to use names at scale. He replaced a centrally copied list with a distributed hierarchy. He separated resolvers from authoritative servers. He made caching and referrals part of the design. He built the first operational implementation and helped others deploy the system.

The result is easy to overlook because it sits between a user’s intention and a network connection. Someone enters a name. A resolver finds an answer. The browser opens a connection. The invisible steps feel automatic.

That invisibility is a mark of successful infrastructure. DNS does not need to announce itself every time it works. It lets names remain in the foreground while the machinery stays behind the interface.

For pdomain, that history is directly relevant. A domain is not merely a word with a suffix. It is a coordinate in a global naming system and a possible foundation for a company’s public identity. The best domain decisions respect both sides: the human meaning of the name and the technical system that carries it.

The Internet changed when a growing network learned to name itself without relying on one fragile table. It continues to change as those names become brands, products, communities and businesses. The original invention remains present in every lookup, every email route and every domain that helps a person find what comes next.

Practical takeaway: when evaluating a domain, ask the same questions that made DNS durable: Can the name scale beyond one use? Can ownership be delegated clearly? Can services remain available when one component fails? Can the identity stay understandable as the business evolves? A good domain is a human-readable promise carried by a resilient technical system.

[1]: https://www.isi.edu/news/972810/and-the-dns-was-born/ "USC Information Sciences Institute: And the DNS was Born" [2]: https://www.internethalloffame.org/inductee/paul-mockapetris/ "Internet Hall of Fame: Paul Mockapetris" [3]: https://awards.acm.org/award_winners/mockapetris_3342151 "ACM: Paul Mockapetris Award Recipient" [4]: https://www.icann.org/resources/pages/bios-2013-07-15-en "ICANN Strategy Panels: Paul V. Mockapetris biography" [5]: https://www.rfc-editor.org/rfc/rfc882 "RFC 882: Domain Names — Concepts and Facilities" [6]: https://www.rfc-editor.org/rfc/rfc883 "RFC 883: Domain Names — Implementation and Specification" [7]: https://commons.wikimedia.org/wiki/File:With_Paul_Mockapetris.jpg "Wikimedia Commons: With Paul Mockapetris.jpg"