Paul Mockapetris designed the Domain Name System (DNS) with arbitrary hierarchical nesting, deliberately rejecting Xerox PARC's rigid three-level directory model to allow infinite scalability. (5:42)
Before DNS, ARPANET host resolution relied on a single centralized text file (HOSTS.TXT) managed by SRI NIC, which required manual telephone updates during Pacific business hours. (0:43)
Mockapetris highlights a stark information asymmetry in Silicon Valley equity, noting that utilizing Section 83(b) elections and Section 1202 QSBS can eliminate 100% of federal capital gains for early startup employees. (46:39)
The transition of country code top-level domains (ccTLDs) like Niue's .nu to European users demonstrated early domain arbitrage, eventually leading Sweden to seize control of the domain for national security. (29:58)
Detailed notes
## Background
This interview was published on YouTube by Ryan Peterman on October 19, 2026. According to the show description, Peterman speaks with Paul Mockapetris, the creator of the internet's Domain Name System (DNS), about the history behind building it and the specific design choices made during its inception.
## TL;DR
Paul Mockapetris discusses how DNS emerged in the early 1980s as an unglamorous engineering chore designed to replace ARPANET's centralized, manually maintained host table. He walks through foundational architectural choices, including arbitrary hierarchical nesting, caching with Time-to-Live (TTL) parameters, and the right-to-left naming structure that enables local resolution. Mockapetris also explores the subsequent commercialization of namespaces, the evolution of the IETF and RFC standards, his transition from physics to computing at MIT, and candid reflections on venture capital dynamics and startup equity structures.
## Atmosphere & style
The conversation carries a frank, irreverent, and conversational tone, driven by Mockapetris's dry wit and lack of pretension about building critical global infrastructure. Rather than romanticizing the birth of the internet, he treats it with pragmatic realism, readily poking fun at bureaucratic inertia, academic gatekeeping, and historical engineering missteps. The dynamic between Peterman and Mockapetris feels like an engaging, unvarnished oral history session, blending deep technical retrospective with street-smart Silicon Valley financial advice.
## Bulletin
- [05:42](https://www.youtube.com/watch?v=LT4iVeUoL18&t=342s) Paul Mockapetris designed the Domain Name System (DNS) with arbitrary hierarchical nesting, deliberately rejecting Xerox PARC's rigid three-level directory model to allow infinite scalability.
- [00:43](https://www.youtube.com/watch?v=LT4iVeUoL18&t=43s) Before DNS, ARPANET host resolution relied on a single centralized text file (HOSTS.TXT) managed by SRI NIC, which required manual telephone updates during Pacific business hours.
- [46:39](https://www.youtube.com/watch?v=LT4iVeUoL18&t=2799s) Mockapetris highlights a stark information asymmetry in Silicon Valley equity, noting that utilizing Section 83(b) elections and Section 1202 QSBS can eliminate 100% of federal capital gains for early startup employees.
- [29:58](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1798s) The transition of country code top-level domains (ccTLDs) like Niue's .nu to European users demonstrated early domain arbitrage, eventually leading Sweden to seize control of the domain for national security.
## Key takeaways
- [00:00](https://www.youtube.com/watch?v=LT4iVeUoL18&t=0s) DNS was initially dismissed as a routine plumbing chore rather than a revolutionary project, giving Mockapetris the creative freedom to ignore proprietary corporate directory models.
- [00:43](https://www.youtube.com/watch?v=LT4iVeUoL18&t=43s) Early ARPANET host resolution was entirely manual, requiring system administrators to call SRI NIC between 9:00 AM and 5:00 PM PT to register new machines in a centralized text file.
- [03:34](https://www.youtube.com/watch?v=LT4iVeUoL18&t=214s) Mockapetris designed DNS to scale to roughly 10 million identities, drawing on lessons from his own prior engineering failures with rigid naming hierarchies.
- [05:42](https://www.youtube.com/watch?v=LT4iVeUoL18&t=342s) DNS introduced decentralized delegation, allowing individual organizations to manage local namespaces independently without central coordination.
- [09:02](https://www.youtube.com/watch?v=LT4iVeUoL18&t=542s) The right-to-left inverted structure of domain names was a deliberate choice to assist local resolution and intelligent autocompletion, unlike left-to-right file paths.
- [11:18](https://www.youtube.com/watch?v=LT4iVeUoL18&t=678s) The monetization of namespaces is a historical pattern seen in other identifier systems, such as the transition of product barcodes from a US-centric 10-digit system to an international 11-digit system.
- [15:08](https://www.youtube.com/watch?v=LT4iVeUoL18&t=908s) To ease skepticism during the multi-year migration to DNS, Mockapetris ran an automated daily synchronization that pulled the legacy SRI host table directly into DNS.
- [16:33](https://www.youtube.com/watch?v=LT4iVeUoL18&t=993s) DNS uses an inverted tree architecture where root servers direct queries to top-level domains (TLDs), which in turn point to authoritative nameservers.
- [18:48](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1128s) Time-to-Live (TTL) caching parameters allowed DNS to scale without catastrophic latency by letting systems cache stable records for up to 24 hours.
- [21:57](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1317s) The National Science Foundation (NSF) rejected Mockapetris's early proposal to use DNS as a universal distributed index of all files and content, dismissing it as impossible to track.
- [25:17](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1517s) Hyperscalers like Cloudflare and Google host free DNS services because reducing resolution latency by fractions of a second directly drives user engagement and corporate revenue.
- [25:17](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1517s) Concerns over DNS privacy are relatively minor compared to modern web advertising exchanges, which query over 150 organizations simultaneously with up to 144 user profiling characteristics.
- [29:58](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1798s) The commercialization of country code top-level domains (ccTLDs) was pioneered by the arbitrage of Niue's .nu, which bypassed bureaucratic European registries to sign up Swedish and French users.
- [33:11](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1991s) The RFC publication process has evolved from an informal, lightweight system managed by Jon Postel into a highly bureaucratic, political standards-track process run by the IETF.
- [38:17](https://www.youtube.com/watch?v=LT4iVeUoL18&t=2297s) Many computing breakthroughs historically attributed to elegant theory, such as chess engines and speech transcription, were actually solved through sheer computational brute force.
- [42:18](https://www.youtube.com/watch?v=LT4iVeUoL18&t=2538s) The most significant professional opportunities often lie at the intersection of two distinct disciplines, such as computational biology or software engineering combined with device physics.
- [44:32](https://www.youtube.com/watch?v=LT4iVeUoL18&t=2672s) Venture capital firms like SoftBank often force startups to scale prematurely, as seen when they mandated a $50 million multi-city launch for Urban Media instead of a pragmatic $5 million trial.
- [46:39](https://www.youtube.com/watch?v=LT4iVeUoL18&t=2799s) Silicon Valley's equity structure often disadvantages ordinary employees due to a lack of financial literacy regarding Section 83(b) elections and Section 1202 Qualified Small Business Stock (QSBS).
## Detailed walkthrough
### [00:00](https://www.youtube.com/watch?v=LT4iVeUoL18&t=0s) The Underestimated Origins of DNS
The interview opens with Paul Mockapetris reflecting bluntly on the architecture he designed for the Domain Name System, acknowledging that his decisions sparked decades of debate: “I make no apologies. And there's a lot of people that think I was wrong.” Despite DNS becoming foundational infrastructure for modern computing, Mockapetris recalls that its inception was largely dismissed as routine plumbing rather than a revolutionary project. At the time, major labs like Xerox PARC were pursuing proprietary, rigid directory architectures, which Mockapetris found fundamentally flawed and chose to ignore.
A recurring theme is the quiet, unmonitored environment in which Mockapetris operated. The assignment was considered a low-stakes engineering chore rather than vital internet infrastructure: “Nobody thought it was that important. It was a nice little problem, you know, go away.” Mockapetris also touches on the economic realities of internet infrastructure, questioning the incentives behind hosting root servers and observing dryly that Silicon Valley has long prioritized venture capitalists over everyday engineers.
---
[00:43](https://www.youtube.com/watch?v=LT4iVeUoL18&t=43s) Networking Before DNS: The Era of Centralized Host Files
Before DNS existed, ARPANET host resolution relied on a single centralized text file managed by the Stanford Research Institute Network Information Center (SRI NIC). Mockapetris began formulating DNS around 1982, tracing network history back to ARPANET’s launch in the late 1960s. In that early era, computers were room-sized or refrigerator-sized monoliths cooled by loud fans and perched on raised subflooring. Because institutions housed only one or two such machines, assigning distinct network names was unnecessary until inter-network communications expanded.
As the network expanded, SRI NIC maintained a central master file mapping hostnames to IP addresses. When Mockapetris first used the system, the entire list was roughly 50 lines long; by the time he began designing DNS, it had grown to a few hundred lines. Registering a machine was completely manual: a system administrator had to telephone SRI NIC during business hours—specifically 9:00 AM to 5:00 PM Pacific Time—to request a new entry. Other institutions on ARPANET only learned about a new computer when they periodically fetched a fresh copy of the master file. Mockapetris compares the system to an analog directory: “So, that file was kind of like the master copy of a phone book and the only way you would become known is when other people on the network would say, 'Hey, give me an updated copy of who's who.'”
```mermaid
flowchart TD
accTitle: Transition from HOSTS.TXT to Distributed DNS Architecture
accDescr: Diagram illustrating the centralized SRI NIC phonebook model versus the decentralized hierarchical DNS model.
subgraph Centralized["Pre-DNS: Centralized HOSTS.TXT Model"]
A["System Administrator"] -->|"phone call (9am-5pm PT)"| B["SRI NIC Master File"]
B -->|"periodic manual download"| C["ARPANET Hosts"]
end
subgraph Distributed["DNS Model"]
D["Client Resolver"] -->|"1. Query root / TLD"| E["Root & TLD Servers"]
E -->|"2. Delegate to NS"| F["Domain Authoritative Server"]
F -->|"3. Instant dynamic answer"| D
end
```
- ARPANET's original host directory was maintained manually by SRI NIC.
- The host table grew from approximately 50 lines in early days to a few hundred lines by 1982.
- Directory updates depended entirely on telephone calls placed during Pacific business hours.
- Updates were non-dynamic and propagated only when remote hosts explicitly pulled an updated copy of the file.
---
[03:34](https://www.youtube.com/watch?v=LT4iVeUoL18&t=214s) Taking on an Unwanted Research Problem
Mockapetris took on the domain name project partly to escape crowded academic research fields. He had been conducting network performance measurement studies, but disliked competing with established luminaries who dominated the literature. The USC Information Sciences Institute (ISI) assigned him the naming problem because nobody viewed it as high-profile. This lack of oversight gave him complete creative freedom, shielding him from conservative guidance that might have constrained his design.
His preparation came from prior engineering failures and distributed computing experiments. As an undergraduate at MIT, he collaborated with the Architecture Machine Group (the predecessor to the MIT Media Lab), which was underfunded at the time and required interconnected machines. Later, at UC Irvine, Mockapetris designed a naming system that he considered poorly conceived. Rather than deriving DNS from consensus within USC ISI or the broader ARPANET committee, Mockapetris treated it as an opportunity to fix his own prior missteps and bypass the design limitations he observed in corporate systems: “It was just based upon I had now done it wrong a couple of times. Okay, this time I was going to get it right.” He designed the system with the ambitious assumption that it would need to scale to roughly 10 million distinct identities.
---
[05:42](https://www.youtube.com/watch?v=LT4iVeUoL18&t=342s) Distributed Management and Arbitrary Hierarchical Nesting
The core breakthrough of DNS centered on decentralized delegation and unified discovery. Under the DNS architecture, an institution contacted a central registry once to delegate an authority boundary; afterward, the organization could create and reconfigure its own hostnames and subdomains independently, with changes propagating immediately rather than waiting on batch phonebook distributions. Crucially, the protocol’s first operational task was recursive discovery: DNS queries did not begin by asking for an IP address, but by locating the authoritative nameserver designated to answer for that slice of the namespace.
A critical design choice was allowing arbitrary depth in domain nesting. At MIT, Mockapetris had built a rigid two-level naming hierarchy, and Xerox PARC had implemented an inflexible three-level naming system. Mockapetris considered arbitrary limits counterproductive: “Xerox PARC at the time I was designing the DNS had their own kind of system, and they had fixed three levels. And I said, 'This is stupid. Okay, I'm just going to design it so that you can nest it however many levels you want.'” Even though typical web properties only leverage three or four levels, infinite nesting allowed complex, hidden applications to structure data without arbitrary protocol constraints. The user-facing result was total abstraction: whether querying a domestic host or a foreign country-code domain like `.fr`, the lookup process remained unified and invisible.
- DNS used its own records to locate authoritative nameservers before resolving machine addresses.
- Delegation allowed individual organizations to administer local namespaces without central coordination.
- Mockapetris deliberately rejected the fixed three-level hierarchy used by Xerox PARC in favor of arbitrary nesting depth.
- The system was architected to present disparate global registries as a single, coherent namespace.
---
[09:02](https://www.youtube.com/watch?v=LT4iVeUoL18&t=542s) Inverted Domain Structure and the Emergence of "www"
Ryan Peterman questions why domain names read right-to-left from most specific to least specific (such as `maps.google.com`), whereas file paths follow a left-to-right hierarchy. Mockapetris vigorously defends the right-to-left order, explaining that starting with the specific host assists local resolution and intelligent autocompletion: “You say inverted, I say it's an obvious choice. Think about this.” If a user types a specific machine name like `maps` or `Alice`, the operating system can immediately test local context or infer the surrounding network domain. Conversely, typing `.com` first provides zero predictive utility, immediately matching over 260 million entries.
Peterman also asks why web URLs came to be prepended with the generic `www` subdomain. Mockapetris explains that in the early internet, distinct protocols shared the same institutional domain name, including File Transfer Protocol (FTP), SMTP mail, and later the World Wide Web. For an institution like Stanford University operating under `stanford.edu`, administrators established functional naming conventions: traffic destined for the file repository went to an FTP host, while traffic intended for the public web was directed to `www.stanford.edu`.
[11:18](https://www.youtube.com/watch?v=LT4iVeUoL18&t=678s) Gaudi’s Cathedral, Failed Additions, and the Monetization of Namespaces
Paul Mockapetris reflects on how the original conceptual model of the internet shifted over time. While people used to think in terms of reaching distinct machines designated for specific services—such as `ftp.stanford.edu`—that paradigm largely faded as nearly all consumer interaction coalesced around web servers like `www.whitehouse.gov`. Mockapetris compares the evolution of DNS to architecture:
> “I always say what I did for the DNS is I built the sub-basement and the basement and the two floors of this building. And then people came along and added a hundred different things.”
He likens the resulting structure to Antoni Gaudí’s Sagrada Família in Barcelona, full of peculiar, sprawling shapes. Because anyone could propose extensions, well over a hundred additions were attempted, though Mockapetris notes that roughly half fell well below average quality. A prime example was an effort by internet engineers to route regular telephone calls through DNS. The designers failed to incorporate nuanced real-world telephone features—such as how toll-free 800 numbers function differently across regional boundaries—resulting in a system functionally inferior to the legacy telephony network it aimed to replace.
When discussing public complaints regarding the commercialization and skyrocketing prices of desirable domain names, Mockapetris observes that this phenomenon has occurred across virtually every identifier system in history. He illustrates this with the creation of product barcodes:
```mermaid
flowchart TD
accTitle: Barcode Namespace Evolution
accDescr: Diagram showing how US barcodes expanded from a 10-digit system into an 11-digit international standard and subsequent commercialization.
subgraph US["US Barcode System"]
A["10-digit barcode standard"] --> B["Charge fee to allocate blocks (e.g. 5,000 codes)"]
end
subgraph Europe["European Expansion"]
C["Europeans refuse to pay US entity"] --> D["Create 11-digit standard<br>(Embed US codes under leading zero)"]
D --> E["Distribute remainder of namespace"]
end
subgraph Commercial["Secondary Monetization"]
F["Airlines request numbers for baggage tracking"] --> G["Namespace owners charge airlines fees to manage blocks"]
end
B -.->|"Europe wants in"| C
E --> F
```
- **Barcode transition**: Barcodes originally operated as a 10-digit US system where organizations purchased blocks of codes (e.g., 5,000 at a time). European organizations resisted paying the US authority and instead engineered an 11-digit system—embedding the US space under a leading zero—and controlled the remainder of the namespace.
- **Subsequent commercialization**: When other industries, such as commercial airlines tracking passenger luggage, requested allocations, the operators turned around and charged them fees, underscoring that namespace governance routinely shifts from cost recovery to monetization.
---
[15:08](https://www.youtube.com/watch?v=LT4iVeUoL18&t=908s) The Early DNS Specification and the SRI Host Table Migration
Mockapetris published the foundational DNS specifications in 1983 (RFC 882 and RFC 883). By 1986, the operational network reached a key turning point when the first host machine was configured to rely purely on DNS without maintaining any local `HOSTS.TXT` flat file.
During the multi-year migration, the broader networking community was intensely skeptical about replacing a local lookup file with remote network queries. Mockapetris explains their reasoning:
> “So, either there's the scheme where I get a copy of this table and when I want to know information, I look it up or I go off and send queries across the internet and see whether or not the right answer comes back. Which one sounds more reliable?”
To bridge this trust gap and guarantee continuity, Mockapetris instituted an automated daily synchronization process:
- Every morning, Mockapetris pulled the latest master host table from SRI (Stanford Research Institute).
- He parsed and loaded all records directly into DNS.
- As early adopters (“the cool kids”) established their own subdomains and published services exclusively in DNS, DNS became a superset containing 100% of the legacy SRI records plus unique new entries unreachable via `HOSTS.TXT`.
---
[16:33](https://www.youtube.com/watch?v=LT4iVeUoL18&t=993s) The Inverted Tree Architecture of the Domain Name System
Mockapetris breaks down the high-level technical architecture of DNS using the computer science concept of an inverted tree, where the root sits at the absolute top and leaf nodes branch downward beneath top-level domains (TLDs) such as `.com` and `.edu`.
While client autocomplete features read from left to right (e.g., matching local names forward), hierarchical domain resolution traverses in reverse, moving down the tree from the root.
```mermaid
flowchart TD
accTitle: DNS Hierarchical Tree Resolution
accDescr: Step-by-step resolution from the root server down to the authoritative school server.
subgraph Resolution["Iterative Tree Traversal"]
Root["Root Server (.)"] -->|"Refers to.edu server"| TLD["TLD Server (.edu)"]
TLD -->|"Refers to stanford.edu server"| SLD["Authoritative Server (stanford.edu)"]
SLD -->|"Returns record for web server"| Answer["Final IP Address"]
end
```
To resolve a destination such as `stanford.edu`:
1. The resolving server consults its small, hard-coded bootstrap list of root servers to locate the root.
2. The root server does not hold individual host mappings, but directs the resolver to the authoritative nameserver handling the `.edu` TLD.
3. The `.edu` nameserver points the client to the authoritative nameserver for `stanford.edu`.
4. As Mockapetris summarizes the structural guarantee: “if you can get to the top, you can always go to the bottom.”
In the original implementation, the entire internet was supported by just 3 root server machines. Today, that foundation has expanded to 13 distinct root server identifier letters, each deployed as an expansive globally distributed cloud of instances.
---
[18:48](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1128s) Caching, Time-to-Live (TTL), and Shifting Bureaucracies
Addressing Ryan Peterman's question about how he proved recursive resolution would not suffer from catastrophic latency or downtime, Mockapetris details the caching and Time-to-Live (TTL) mechanisms embedded into query responses. Records return with an explicit expiration parameter designating how many seconds the response remains valid.
Mockapetris uses a household kitchen metaphor to explain DNS TTL caching behavior:
- **Milk**: Short lifespan, best used within a week.
- **Canned beans in the pantry**: Long shelf life, “best if used this century.”
Because internet records often point to stable servers that do not change from day to day, administrators could set TTL values of a full 24 hours. Consequently, systems pay the full network round-trip resolution cost only once across hundreds or thousands of subsequent accesses.
Beyond performance benefits, economic and organizational forces hastened the transition away from centralized host tables. In the early days of ARPANET, the SRI Network Information Center (NIC) managed the entire global directory with a team of just three people. As the internet exploded, an influx of network administrators flooded the SRI staff with phone calls demanding host table additions. Because the United States Department of Defense (DoD) funded SRI's contract, defense leadership began to balk at the escalating administrative costs of manually registering non-military institutions like `stanford.edu`, making an automated, delegated domain system an operational necessity.
[21:57](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1317s) The Expansion of NSFNET, the Birth of MILNET, and Rejected Research Proposals
As the network expanded with NSFNET and was no longer managed strictly by ARPA or the Defense Data Network (DDN), funding questions quickly arose. Maintaining the host list and network operations eventually required a staff of around 20 people. Network operators asked why they should bear the expense of running infrastructure for everyone else, concluding that they should only pay to maintain systems for their own users. This shift sparked the separation of MILNET, creating a dedicated network reserved for real military use.
Around the late 1980s, Paul Mockapetris experienced a similar withdrawal of research interest from ARPA. Mockapetris explains that ARPA told him: “Paul, this isn't research anymore. It's all done deal. It was a great thing, but it's not new and super wizzy and innovative and so forth. So we're not going to pay you anymore for that.” When he submitted a proposal outlining what he envisioned as the next generation of DNS, ARPA dismissed it as old technology rather than cutting-edge science.
Mockapetris then submitted a proposal to the National Science Foundation (NSF) proposing a radical expansion: using DNS not merely for hostnames, but as a universal distributed index of all files and content across the network. The NSF rejected the idea out of hand, saying: “Paul, you're crazy. There's like thousands of machines. You can't possibly keep up with all of that, okay?” Looking back, Mockapetris jokes that this was one of his fundamental miscalculations, comparing it to failing to register 10,000 domain names early to sell later on a beach, or missing out on mining billions of dollars of Bitcoin on a 286 laptop.
```mermaid
flowchart TD
accTitle: Evolution of DNS Funding and Network Separation
accDescr: Flowchart showing how DDN and ARPA maintenance costs led to MILNET separation and the rejection of early DNS content indexing proposals.
subgraph Operations["Network Operations Split"]
A["Single central staff (~20 people)<br/>maintains host tables"] --> B["DDN / ARPA balk at costs<br/>for external users"]
B --> C["MILNET splits off for<br/>military-only infrastructure"]
end
subgraph Proposals["Mockapetris Research Proposals"]
D["Next-Level DNS Proposal"] -->|Rejected| E["ARPA: DNS is no longer<br/>cutting-edge research"]
F["Global Content Index Proposal"] -->|Rejected| G["NSF: Thousands of machines<br/>are impossible to track"]
end
```
[25:17](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1517s) Root Server Economics, Hyperscaler Centralization, and the Reality of Internet Privacy
Ryan Peterman asks what economic incentive exists for entities to operate the 13 root server clouds when doing so at hyperscale requires substantial financial investment. Mockapetris admits that the underlying motivation remains somewhat puzzling to him: “I asked myself this question a lot. And I have to tell you it's one of the things I don't quite understand.” Early on, Mockapetris personally lobbied organizations to host root servers, offering them the code directly, until European organizations eventually came forward demanding a European root server of their own.
Mockapetris observes that while the system was originally deeply distributed, it is increasingly centralized and subsumed by major hyperscalers like Cloudflare and Google. As protocols grew more convoluted, running independent services became prohibitive. The "internet old boys" often lament that running an email server used to be simple, whereas modern systems require complex load balancing and specialized operational expertise, pushing organizations to outsource. While skeptics suspect hidden motives or data harvesting behind companies running free root or resolver services, Mockapetris points out that direct commercial incentives exist: companies like Microsoft know precisely how milliseconds of latency impact platforms like LinkedIn. Accelerating DNS resolution yields higher user engagement and direct profit.
Addressing concerns over DNS privacy, Mockapetris argues that fixating on DNS tracking misses the far larger reality of commercial data collection on the web: “DNS may be a privacy risk, but your privacy gets violated in so much more effective ways by all of this web stuff. You know, it's like it doesn't make it to the metal round of privacy invasion.” He highlights that when a single webpage ad loads, more than 150 organizations are queried in real time with up to 144 profiling characteristics of the target user, rendering standard DNS data comparatively trivial.
- Early DNS root server rollout depended on Mockapetris pitching volunteers; later, geographic regions pushed for local instances (such as European roots) driven by prestige and sovereignty.
- Hyperscaler DNS services are partly driven by performance optimization: reducing page load times by fractions of a second directly drives user engagement and corporate revenue.
- Web advertising exchanges query 150+ organizations simultaneously, transmitting up to 144 demographic and behavioral attributes per impression, far outpacing the privacy risks of DNS queries.
[29:58](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1798s) Country Code Arbitrage: The Story of .nu and ccTLD Commercialization
Mockapetris recounts how country code top-level domains (ccTLDs) were delegated to individual countries, leaving local policies entirely in national hands. In nations such as France (`.fr`) and Sweden (`.se`), registration involved bureaucratic delays, paperwork, and mandatory cash deposits.
An enterprising acquaintance recognized an arbitrage opportunity through the South Pacific island nation of Niue. Allocated the `.nu` country code, the island agreed to let this entrepreneur operate their top-level domain in exchange for a share of the revenue. He turned around and marketed `.nu` directly to French and Swedish internet users, charging a modest flat fee of around 10 kronor per domain with instantaneous setup. Demand exploded:
- In Swedish and French, "nu" carried connotations of "new," "cool," or "nude," making it an attractive novelty domain.
- Thousands of European businesses and individuals bypassed their domestic registries' red tape by setting up on `.nu`.
- The situation eventually triggered an international ownership battle; Swedish authorities intervened and assumed operational control over `.nu`, arguing that the sheer volume of Swedish businesses relying on the domain elevated its stability to a national security issue for Sweden.
Peterman and Mockapetris conclude that this dynamic paved the way for modern ccTLD commercial windfalls, such as the Caribbean island of Anguilla capitalizing on the artificial intelligence boom with `.ai`, and Colombia providing an alternative to `.com` via `.co`.
[33:11](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1991s) The Evolution of RFCs and Internet Governance
Ryan asks Paul Mockapetris about the engineering culture behind RFCs (Requests for Comments), noting that from a high level, they appear to serve as formal engineering proposals. Mockapetris explains that the culture and process have shifted dramatically over the decades. In the early days, publishing an RFC was an informal, lightweight affair. When he wrote the foundational specifications for the Domain Name System—RFC 882 and RFC 883—the mechanism was straightforward because his immediate boss happened to be Jon Postel, the RFC Editor who handed out the numbers. Postel would assign an RFC number, post the document onto an accessible server, and engineers across the network would simply download it.
Over time, that informal sharing was replaced by institutional bureaucracy with the creation of the Internet Engineering Task Force (IETF). Today, RFCs follow strict procedural paths. There are informational RFCs—where someone can publish an idea as long as it is reasonably cogent—and standards-track documents, which involve substantial politics, paperwork, and procedural hurdles. Mockapetris observes a historical irony in how institutional credit is claimed, pointing out that the IETF often takes credit for the creation of DNS despite the timeline: “Now, one of the problems with that is that the DNS spec came out in 1983 and the first meeting of the IETF was in 1986.”
```mermaid
flowchart TD
accTitle: Early RFC Publication vs Modern IETF Process
accDescr: Diagram contrasting the simple author-to-server RFC publication flow in 1983 with the formal standards track established after the creation of the IETF in 1986.
subgraph Early ["Early Era (circa 1983)"]
A["Author writes spec\n(e.g., RFC 882/883)"] --> B["RFC Editor assigns number\n(Jon Postel)"]
B --> C["Spec uploaded to server\nCommunity downloads directly"]
end
subgraph Modern ["Modern Era (IETF post-1986)"]
D["Proposal Submitted"] --> E{"RFC Category"}
E -->|"Informational"| F["Cogent technical write-up\nPublished with RFC number"]
E -->|"Standards Track"| G["Working groups, politics,\npaperwork, and formal consensus"]
end
```
[35:07](https://www.youtube.com/watch?v=LT4iVeUoL18&t=2107s) From Physics to Computing: An Academic Intervention at MIT
Asked how he entered computing at a time when the field was still niche rather than ubiquitous, Mockapetris recounts starting out as a physics major. Intrigued by an MIT summer class he took during high school, he arrived at MIT fascinated by physics, inspired by post-World War II enthusiasm and promises such as nuclear power being "too cheap to meter." However, needing extra money as an undergraduate, he looked at his campus employment options: he could either work in food service or take an entry-level programming gig. Because programming paid better from day one, he chose computers.
Mockapetris picked up programming assignments across Cambridge, working at the IBM Cambridge Scientific Center, the Draper Laboratory, and the Architecture Machine Group (the precursor to the MIT Media Lab). By his junior year, his physics advisor and the head of the IBM Cambridge Scientific Center took him out to lunch for an intervention. They told him plainly that while he was not particularly talented as a physicist, he showed real aptitude for computer work. To accommodate his desire to complete what he had started, they offered a compromise: they would grant him his physics bachelor's degree—treating it essentially as a "learner's permit"—while enabling him to double-major and finish a degree in computer science so he could focus on what he did best.
In the Architecture Machine Group, computing had to be practical. Because the department was not considered high-priority, they were only allocated minicomputers rather than massive mainframes. To compensate, the lab networked these smaller machines together to share workloads and distributed tasks—anticipating concepts later popularized by cloud computing, and paralleling ARPA-funded distributed computing research being conducted at Carnegie Mellon University.
[38:17](https://www.youtube.com/watch?v=LT4iVeUoL18&t=2297s) AI Cycles, Brute Force, and Early Infinite Compute
Reflecting on whether the early growth of the internet felt like the current generative AI boom, Mockapetris explains that he does not view AI through the same intuitive lens because he grew up inside the core architecture of the internet as it expanded. Furthermore, he points out that the current enthusiasm around AI represents “the second or third coming of AI.” He recalls attending a major AI conference in Marina del Rey around 1985 when enthusiasm crested, only for the discipline to enter a prolonged downturn. Historically, agencies like ARPA funded projects hoping that faster, larger hardware clusters would finally make artificial intelligence work.
Mockapetris observes that milestones once viewed as true intelligence—such as teaching a machine to play grandmaster-level chess or transcribing human speech—ultimately succeeded through sheer computational scale rather than elegant theory:
- **Chess and Speech:** Breakthroughs occurred once engineers assembled massive databases and enough raw processing power to solve the problem by brute force.
- **Large Language Models:** Modern LLMs run on vast computational scale, relying on mechanized trial and error: “It can do more errors and more trials than you can imagine. Um but it gets results.”
Unlike contemporary students who had to budget scarce computer time down to the minute, Mockapetris enjoyed an unusual computing privilege. Alongside his minicomputer work at MIT, his part-time post at the IBM Cambridge Scientific Center granted him unrestricted access to the most powerful mainframes IBM manufactured. Because IBM wanted him running tasks that burned significant machine cycles, he never faced resource rationing, quipping that he essentially "time traveled" relative to his peers because he always had as much compute capacity as he could consume.
[42:18](https://www.youtube.com/watch?v=LT4iVeUoL18&t=2538s) Opportunities at the Edge of Disciplines and Missed Startups
Looking back on his career and the advice he gives to students, Mockapetris highlights that the biggest opportunities consistently appear at the intersection of two distinct domains. He points to computational biology as an obvious example—a discipline that did not exist when he was in school, but is now completely intertwined with computer science. Early on, his dual background allowed him to secure lucrative consulting work with Digital Equipment Corporation (DEC). DEC needed someone who could simultaneously write software and speak the language of semiconductor device physicists; Mockapetris was hired on the spot after proving he could bridge both technical worlds.
Mockapetris admits his biggest professional regrets stemmed from failing to recognize the commercial opportunities sitting at those boundaries. When he developed an indexing proposal that ARPA and the National Science Foundation (NSF) rejected on the grounds that it was not fundamental academic research, he simply accepted the rejection instead of realizing venture capital existed to back those exact ideas: “If I had been smart enough to know that, well, the people at Sand Hill Road might fund me to go start a company there.” He estimates there were at least half a dozen times in his career where he had viable company concepts, but held back because he mistakenly believed starting a business required personal mastery of accounting and corporate mechanics, unaware that founders could delegate bookkeeping and pitch venture firms on Sand Hill Road for capital.
[44:32](https://www.youtube.com/watch?v=LT4iVeUoL18&t=2672s) Pitching SoftBank and the Venture Capital Mindset
Paul reflects on the mindset required to navigate Silicon Valley, sharing a memorable war story about dealing with mega-investors. “Once upon a time I had the privilege of introducing SoftBank to its biggest failure,” he remarks, recalling a startup named Urban Media. The founders initially approached SoftBank with a measured, pragmatic proposal: raise roughly $5 million, deploy their system in three test cities, and expand outward only if the model proved viable. SoftBank flatly rejected that incremental approach, telling them: “No. Think big or go home. Um you'll have to do it in all and this is the way they put it. All of the NFL cities and LA.” Instead of the proposed modest initial budget, SoftBank insisted on launching with around $50 million, ultimately leading the company to burn through over $100 million—an enormous sum for that era.
Paul notes that understanding the psychology of Sand Hill Road venture capitalists is an entirely distinct discipline, and he wonders in hindsight why he did not start more companies of his own. He observes that technical students often profess a desire to avoid business entirely, but he stresses that engineers must understand at least enough business fundamentals to recognize the operational support they require. While engineers in startups frequently look down on salespeople and marketers, Paul insists those functions are indispensable to survival. Opportunity, he explains, comes from reconnaissance and identifying leverage where technical expertise intersects with complementary fields.
- Paul pitched an initial $5M roll-out across three trial cities for Urban Media; SoftBank mandated scaling immediately to every NFL city plus Los Angeles, starting with a $50M budget and ultimately burning over $100M.
- Engineers who dismiss sales, marketing, and accounting do so at their own peril, as business literacy is critical for turning technical ideas into viable enterprises.
- “Well, but you need to understand enough about business so that if you want to start one, you can figure out, yeah, okay, I need an accountant.” — Paul Mockapetris
---
[46:39](https://www.youtube.com/watch?v=LT4iVeUoL18&t=2799s) Advice to Younger Self, Section 1202 QSBS, and Silicon Valley Equity
When asked what advice he would offer his younger self, Paul immediately quips that he should have paid attention in high school French. At the time, he loathed the subject because his teachers were World War I veterans suffering from severe shell shock; his homeroom French teacher notably ate potato chips and Jell-O with a knife and fork. Ironically, Paul later spent eight years living in France. He uses this anecdote to illustrate that all knowledge is inherently useful, because one can never predict where life will demand its application, meaning engineers should operate as intellectual sponges and push outside their comfort zones.
```mermaid
flowchart TD
accTitle: Equity Taxation Comparison Under QSBS and 83b
accDescr: Diagram illustrating how early exercise via Section 83b and QSBS reduces tax burden compared to standard NSOs.
subgraph StandardOptions["Standard Option Path"]
A["Grant of Options"] --> B["Wait for Vesting"]
B --> C["Exercise at Higher Valuation\n(e.g., $0.10/share vs $0.01 strike)"]
C --> D["Taxed on Gain at Exercise\n(NSO Ordinary Rates up to ~65%)"]
end
subgraph EarlyExercisePath["Section 83(b) + Section 1202 Path"]
E["Grant of Options"] --> F["Immediate Early Exercise\nvia Section 83(b) at $0.01/share"]
F --> G["Company Retains Repurchase Right\nif Employee Leaves"]
G --> H["Hold Stock for Required Period\nunder Section 1202 (QSBS)"]
H --> I["0% Federal Capital Gains\nupon Company Acquisition"]
end
```
Turning to financial literacy, Paul argues that conventional startup culture conceals equity mechanics from ordinary rank-and-file employees to the disproportionate benefit of venture capitalists. “And Silicon Valley pretty much screws the peons and rewards the VCs. And the only difference is a kind of a lack of knowledge,” Paul asserts. He points specifically to Section 1202 Qualified Small Business Stock (QSBS) and Section 83(b) tax elections. When an employee receives stock options, they typically wait until vesting to exercise; if the valuation has increased from one cent to ten cents, the employee immediately faces a taxable spread upon exercise and may face punishing tax rates—up to 65% when combining federal and California state taxes on non-qualified stock options (NSOs). Conversely, filing an 83(b) election allows early exercise at grant when the stock is virtually worthless, locking in the low baseline cost and starting the holding clock for QSBS treatment.
Paul recounts an acquisition where he sat on the board as a Series A investor. He wanted to inform the company's rank-and-file employees about Section 1202 so they could legally shield their gains, but the acquiring entity explicitly forbade leadership from discussing it, preferring that employees not make waves. During that payout, Paul realized the stark inequality firsthand: his Series A preferred stock paid standard long-term capital gains, his unexercised options faced punishing top-tier income tax rates, but the common shares he had early-exercised under an 83(b) election qualified under QSBS and incurred zero federal tax. In a subsequent company, Paul formally demanded the employee roster, citizenship breakdown, and corporate capitalization records before an exit so that proper documentation existed. While legal counsel strictly prohibited management from giving direct tax advice, Paul and his colleagues handed over the corporate records alongside a subtle nudge: “you probably want to go read 1202, by the way.”
- Under Section 83(b), an employee exercises unvested stock early at nominal fair market value (e.g., $0.01/share); if the employee leaves, the company repurchases the unvested portion at cost, but the tax basis and holding clock are firmly established on day one.
- Section 1202 QSBS can eliminate up to 100% of federal capital gains on qualifying small business stock held for the statutory period, provided the company meets size thresholds, is not in an excluded category (such as banking or real estate), and satisfies citizenship criteria.
- Paul estimates that roughly 50% of startup workers overpay their taxes due to structural information asymmetry and a lack of access to foundational corporate records.
- “Silicon Valley, there's a hierarchy there. And it isn't like everybody gets the entrepreneurial spirit and everybody gets the same privileges.” — Paul Mockapetris
---
[52:56](https://www.youtube.com/watch?v=LT4iVeUoL18&t=3176s) Host Wrap-Up and Ergonomic Keyboard Project
Ryan Peterman wraps up the interview, thanking Paul for sharing the history of DNS and his experiences across the computing industry. In his closing remarks, Ryan encourages listeners to support the show through comments, likes, and guest suggestions, pointing out that previous landmark interviews—including discussions with Barbara Liskov, Mike Stonebraker, and Mark Brooker—came directly from audience recommendations left in the comments.
Ryan also highlights his personal hardware side project: a split ergonomic keyboard prototype that he designed. He explains that the project was launched on Kickstarter and managed to surpass its full funding goal within eight hours of going live. With the crowdfunding milestone achieved, the project has entered the tooling and manufacturing phase, though Ryan notes that late pledges remain open via Kickstarter for viewers interested in securing a unit.
## Notable quotes
> [11:18](https://www.youtube.com/watch?v=LT4iVeUoL18&t=678s) I always say what I did for the DNS is I built the sub-basement and the basement and the two floors of this building. And then people came along and added a hundred different things. — Paul Mockapetris
> [46:39](https://www.youtube.com/watch?v=LT4iVeUoL18&t=2799s) Silicon Valley pretty much screws the peons and rewards the VCs. And the only difference is a kind of a lack of knowledge — Paul Mockapetris
> [25:17](https://www.youtube.com/watch?v=LT4iVeUoL18&t=1517s) DNS may be a privacy risk, but your privacy gets violated in so much more effective ways by all of this web stuff. — Paul Mockapetris
## Mentioned
Paul Mockapetris, Ryan Peterman, Jon Postel, Barbara Liskov, Mike Stonebraker, Mark Brooker, Antoni Gaudí, Domain Name System (DNS), ARPANET, NSFNET, MILNET, Defense Data Network (DDN), SRI Network Information Center (SRI NIC), USC Information Sciences Institute (ISI), MIT Architecture Machine Group, MIT Media Lab, Xerox PARC, IBM Cambridge Scientific Center, Draper Laboratory, Digital Equipment Corporation (DEC), Cloudflare, Google, Microsoft, LinkedIn, SoftBank, Urban Media, Internet Engineering Task Force (IETF), National Science Foundation (NSF), DARPA / ARPA, United States Department of Defense (DoD), RFC 882, RFC 883, Section 1202 QSBS, Section 83(b)
## Video description
This interview is with Paul Mockapetris, the creator of the internet's Domain Name System (DNS). I talked to him about the story behind building it and certain design choices he made.
• My ergonomic keyboard project I mentioned, you can follow along here: https://read.compose.llc/
• The Kickstarter page for it: https://www.kickstarter.com/projects/ryanlpeterman/compose-simple-ergonomics-beautifully-done
• WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://workos.com/
𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀:
00:00 Intro
00:40 What computing was like before DNS
09:02 Why URLs are inverted
16:33 How DNS works
20:27 How he migrated the internet to DNS
25:17 Why do companies host DNS servers
33:17 What is an RFC
35:07 How he got into computing
46:39 Advice for his younger self
52:56 Outro
DNS诞生背后的故事 | Paul Mockapetris
Paul Mockapetris讲述了DNS在20世纪80年代初如何作为一项不起眼的工程杂务诞生,旨在替代ARPANET集中且人工维护的主机表。他梳理了多项基础架构设计决策,包括任意层次嵌套、带TTL参数的缓存机制,以及支持本地解析的从右到左命名结构。Mockapetris还探讨了命名空间的后续商业化、IETF和RFC标准的发展演进、他从麻省理工学院物理系转向计算机领域的经历,并对风险投资机制及初创公司股权结构做出了坦率反思。
Paul Mockapetris在设计域名系统(DNS)时采用了任意层次嵌套,特意弃用了施乐帕罗奥多研究中心(Xerox PARC)死板的三级目录模型,以实现无限的可扩展性。 (5:42)
在DNS出现之前,ARPANET的主机解析依赖由SRI NIC维护的单一集中式文本文件(HOSTS.TXT),该文件需在太平洋时间工作时间内通过人工电话进行更新。 (0:43)
Mockapetris强调了硅谷股权结构中严重的信息不对称,指出利用83(b)选举机制和1202条款(合格小型企业股票QSBS),初创公司早期员工可以免除100%的联邦资本利得税。 (46:39)
纽埃岛的.nu等国家及地区顶级域名(ccTLD)向欧洲用户的转移展示了早期的域名套利,最终促使瑞典出于国家安全考虑接管了该域名的控制权。 (29:58)
Reading summary
Paul Mockapetris reflects on architecting the Domain Name System (DNS) as an overlooked low-stakes chore, explaining how its decentralized hierarchy replaced manual directories, while critiquing the commercialization, power imbalances, and financial blind spots of the modern tech landscape.
From Centralized Phonebooks to Distributed Delegation (0:43)
Before DNS, network host resolution relied on a centralized text file (HOSTS.TXT) maintained manually by the Stanford Research Institute Network Information Center (SRI NIC). By 1982, the file had grown from 50 to several hundred lines, requiring administrators to telephone SRI during Pacific business hours to register new hosts, with updates propagating only via periodic manual downloads. Assigned the project at USC ISI because senior researchers saw naming as unglamorous plumbing, Mockapetris was granted full autonomy to redesign the architecture.
Mockapetris instituted a decentralized delegation model with recursive discovery: queries located the authoritative nameserver for a specific namespace rather than an IP address directly. Crucially, he rejected the rigid hierarchies used by contemporary systems—such as Xerox PARC's fixed three-level directory—in favor of arbitrary nesting depth, architected to scale to 10 million distinct identities. To bridge skepticism over querying remote servers rather than consulting local files, Mockapetris ran an automated daily script that synchronized the SRI master table into DNS, ensuring DNS was a full superset of legacy records before the first machine fully eliminated its local host file in 1986.
Inverted Hierarchies, Caching, and Bureaucratic Drivers (9:02)
Mockapetris defends the right-to-left order of domain names (such as maps.google.com), noting that leading with specific local machine names enables operating systems to infer context and autocomplete, whereas starting with top-level domains like .com offers zero predictive value. In resolution, the hierarchy operates as an inverted tree: a resolver queries root servers, which direct traffic downward to top-level domains (.edu) and subsequent authoritative servers (stanford.edu). In early implementations, just three root server machines carried the entire internet, which later evolved into 13 root identifier letters operated across distributed clouds.
To prevent catastrophic latency across distributed lookups, DNS implemented Time-to-Live (TTL) record expiration, operating like pantry goods with set lifespans—allowing stable records to be cached locally for 24 hours and amortizing round-trip costs across thousands of queries. The transition away from centralized files was also forced by economic friction: SRI NIC's directory management team expanded to handle soaring call volumes, prompting the Department of Defense to balk at funding administrative overhead for non-military institutions and eventually splitting off MILNET.
Namespace Commercialization and Hyperscaler Centralization (11:18)
Mockapetris compares the evolution of DNS to Antoni Gaudí’s Sagrada Família, observing that while he built the structural basement and lower floors, over a hundred subsequent feature additions were layered on top, often with poor results—such as a failed attempt to route telephony through DNS that lacked basic support for regional 800 numbers. Furthermore, he views the secondary monetization and commercialization of domains as historically inevitable, drawing parallels to how US 10-digit barcodes expanded into European 11-digit systems and subsequent fee-based licensing for baggage tracking.
Arbitrage also emerged in country-code domains (ccTLDs). For instance, Niue's .nu was marketed to French and Swedish users seeking to bypass domestic bureaucratic delays, eventually prompting the Swedish government to take operational control due to widespread business reliance. In modern infrastructure, Mockapetris notes that running independent services has grown increasingly prohibitive, leaving root resolution and DNS traffic increasingly concentrated in hyperscalers like Cloudflare and Google. While some suspect data exploitation, Mockapetris points to latency optimization as a direct commercial driver for platforms like Microsoft's LinkedIn, adding that web advertising exchanges—querying over 150 organizations across 144 attributes per ad—pose far greater privacy intrusions than DNS queries.
Institutional Shifts, Discipline Intersections, and Startup Lessons (33:11)
Internet governance transformed over decades: while early RFCs like RFC 882 and RFC 883 were published informally via RFC Editor Jon Postel in 1983, the later creation of the IETF in 1986 established bureaucratic standards tracks that Mockapetris notes often retroactively take credit for DNS. After ARPA discontinued his funding on the grounds that DNS was no longer cutting-edge research, the National Science Foundation (NSF) rejected his proposal to turn DNS into a distributed index for network files, claiming thousands of machines were impossible to track.
Reflecting on his career trajectory, Mockapetris highlights that breakthrough opportunities reside at the boundaries of fields, such as his early work bridging software engineering and device physics for Digital Equipment Corporation. However, he regrets not pursuing venture capital for his research concepts due to the mistaken belief that founders needed personal mastery over corporate accounting. Citing an aggressive venture experience with SoftBank—which forced a startup named Urban Media to expand immediately into every NFL city with an initial $50 million budget, burning over $100 million—he stresses that engineers must respect sales, marketing, and corporate administration rather than dismissing them.
Equity Asymmetry and Tax Literacy in Silicon Valley (46:39)
Mockapetris argues that conventional startup culture conceals equity mechanics from rank-and-file employees, creating an information asymmetry that disproportionately benefits venture capitalists over workers. He estimates that roughly 50% of startup employees overpay their taxes due to a lack of guidance regarding Section 83(b) elections and Section 1202 Qualified Small Business Stock (QSBS).
When holding non-qualified stock options (NSOs) until vesting, employees often face combined federal and California state taxes of up to 65% on the valuation spread upon exercise. Conversely, filing an 83(b) election allows workers to early-exercise unvested stock at nominal cost, establishing an early cost basis and starting the clock for Section 1202 QSBS treatment, which can eliminate up to 100% of federal capital gains upon acquisition. Mockapetris recounts cases where acquiring companies barred management from explaining these provisions to employees, prompting him to subtly share corporate capitalization records to help workers access tax parity.
Mockapetris demonstrates how basic engineering compromises designed around resource scarcity evolved into foundational, heavily monetized global infrastructure. He leaves open the question of how distributed systems can resist creeping centralization by hyperscalers when protocol complexity routinely exceeds the operational capacity of independent operators.
精炼阅读摘要
Domain Name System(DNS)创造者Paul Mockapetris指出,该系统最初仅被视为一项缺乏学术光环的工程杂务,却因未受过度干预而获得了任意层级嵌套与分布式授权的设计自由;他同时反思了网络命名空间的商业化必然性、现代基础设施的再中心化,以及普通工程师因商业认知匮乏在硅谷股权分配中所承受的结构性损失。
主机表向分层分布式DNS的演化 (0:43)
在DNS诞生前,ARPANET的主机地址解析完全依赖Stanford Research Institute Network Information Center(SRI NIC)维护的单一文本文件HOSTS.TXT。该文件早期仅约50行,到1982年扩增至数百行,新机器注册必须在太平洋时间工作时间内通过电话人工申请,且依赖各节点定期手动拉取。Mockapetris于1982年前后接手该问题,他认为以往系统(如Xerox PARC固定的三级结构或MIT的两级结构)的目录设计过于僵化,因而在1983年发布RFC 882与RFC 883时,确立了允许任意层级嵌套的倒置树状架构,并将域名设计为由具体主机向通用域(从右向左解析)的结构,以支持本地前缀自动补全。
分布式授权、TTL缓存与平稳迁移 (15:08)
DNS的核心突破在于去中心化授权与递归发现:机构仅需向中央注册中心申请一次权限边界,随后即可自主管理二级域名与子节点;解析的第一步是定位负责该区域的权威域名服务器,而非直接索取IP地址。为解决跨网络递归查询带来的延迟与停机疑虑,系统引入了TTL(生存时间)缓存机制,使静态记录无须频繁重复往返查询。在1983年至1986年网络迁移期间,针对社区对远程网络查询可靠性的怀疑,Mockapetris每日清晨自动拉取SRI主表并导入DNS,使DNS成为包含100%旧记录及新专属子域的超集,最终在1986年实现了首台完全脱离本地HOSTS.TXT运行的主机。
命名空间商业化与顶级域名套利 (11:18)
Mockapetris将DNS的演化比作高迪的圣家堂,自己仅构建了地下室与基础楼层,后续涌现的上百种扩展提议中约有一半质量低下(例如试图通过DNS路由常规电话的失败尝试)。他指出,所有标识符系统终将走向商业化变现,正如条形码从美国最初的10位代码演变为欧洲主导的11位标准并向航空公司行李追踪收费一样,域名空间同样催生了利益分配机制。由于维护成本激增,美国国防部早年因不愿承担非军方机构的注册开支而分离出MILNET网络;而国家代码顶级域名(ccTLD)的分配也引发了商业套利。例如针对瑞典(.se)和法国(.fr)繁琐的官僚审核,有创业者取得纽埃岛.nu域名的运营权并以廉价快速的模式向欧洲转售,引发注册狂潮,最终迫使瑞典官方以国家安全为由介入接管,这一逻辑也延续至当代.ai与.co的商业变现中。
根服务器经济学、再中心化与隐私争议 (25:17)
早期整个互联网仅由3台根服务器支撑,如今已扩展为由13个字母标识构成的全球分布式云集群。针对运行根服务器缺乏直接收费机制的疑问,Mockapetris表示其动因已从早期的志愿游说和地缘主权诉求,转向现代超大规模服务商(如Cloudflare和Google)的深度介入。随着协议复杂化,个人自建解析服务的门槛大幅提高,推动了基础设施的再中心化;科技巨头优化解析性能的核心动力之一在于毫秒级延迟降低可直接提升平台(如LinkedIn)的用户参与度与商业回报。针对DNS隐私泄露的担忧,Mockapetris直言其风险被过度放大:在现代Web广告生态中,单个广告加载便可能实时向150多家机构广播包含多达144项用户特征的数据,其监控深度远超基础的域名查询。
交叉学科边界、资本思维与股权不平等 (42:18)
结合个人从物理转向计算机的研究经历,Mockapetris建议工程师重视交叉学科的杠杆机会。他反思自己曾因缺乏商业常识,在ARPA和NSF相继拒绝资助其下一代分布式内容索引提案后,未能向风险投资寻求支持;而在协助Urban Media向软银融资时,资方断然否决了以500万美元在3个试点城市验证的务实方案,强制要求以5000万美元预算铺开至全美所有NFL城市及洛杉矶,最终导致该项目烧蚀逾1亿美元。
在个人财务与创业分配上,Mockapetris批评硅谷文化在股权机制上存在严重的信息不对称,往往倾向于风险投资人而牺牲普通员工利益。他指出,若员工仅在行权期后被动等待,行权时将面临高额普通收入税负(联邦加加州税率最高可达约65%);但若利用Section 83(b)在获授初期以极低估值提前行权,并满足Section 1202合格小企业股票(QSBS)的持有条件,可在公司被收购时免除最高100%的联邦资本利得税。他估计约有50%的初创企业员工因缺乏资本常识及无法获取基础公司文件而过度缴纳了税款。
Mockapetris的经历表明,底层网络架构的设计不仅取决于技术方案的优劣,更深嵌于资金供给、行政博弈与商业激励之中。从避开主流学术争论而诞生的DNS,到如今被巨头集中化并伴随复杂的资本与税务博弈,工程实现始终无法脱离现实利益结构;技术人员若要维系自身的创造价值,必须跨越纯技术视角的局限,理解商业杠杆与资本分配规则。
Source quotes
[11:18] Paul Mockapetris: I always say what I did for the DNS is I built the sub-basement and the basement and the two floors of this building. And then people came along and added a hundred different things.
[46:39] Paul Mockapetris: Silicon Valley pretty much screws the peons and rewards the VCs. And the only difference is a kind of a lack of knowledge
[25:17] Paul Mockapetris: DNS may be a privacy risk, but your privacy gets violated in so much more effective ways by all of this web stuff.
Original transcript
[0:00] I make no apologies. And there's a lot
[0:01] of people that think I was wrong.
[0:03] >> This is Paul Mockapetris who created the
[0:06] Domain Name System or DNS, and I
[0:08] interviewed him for the stories behind
[0:10] its creation.
[0:11] >> Nobody thought it was that important. It
[0:13] was a nice little problem, you know, go
[0:15] away.
[0:16] Xerox PARC, at the time I was designing
[0:18] the DNS, had their own kind of system,
[0:21] and I said, "This is stupid."
[0:22] You say inverted, I say it's an obvious
[0:25] choice. Think about this.
[0:27] >> Those root servers, who's paying for
[0:28] those servers? What's the economic
[0:30] incentive?
[0:31] >> Silicon Valley pretty much screws the
[0:33] peons and rewards the VCs. The only
[0:37] difference is
[0:38] >> Here's the full episode.
[0:43] Yeah, before we talk about DNS getting
[0:45] created, I'd like to go over what was
[0:48] computing like before DNS.
[0:50] >> Well, it depends on where, how far
[0:52] before DNS. Uh, you know, but just to
[0:55] put a post in the ground, I started
[0:58] thinking about DNS probably in 1982.
[1:01] Now, to backspace over that, the ARPANET
[1:04] was created in the late '60s. So,
[1:07] computers were being connected, so that
[1:10] meant that there would be more than one
[1:12] computer on the network. Obviously, if
[1:14] you only have a computer in a big lab,
[1:17] you don't need to name it unless you
[1:19] feel like it, cuz it isn't like which
[1:22] computer do you want to talk to is ever
[1:23] an issue. But, when you start networking
[1:25] together, then the question comes up,
[1:28] how do you decide which one you want to
[1:30] talk to from whichever one you happen to
[1:33] be at? Cuz in these days, the computers
[1:36] we're talking about were big machines.
[1:38] Uh, you know, at least refrigerator
[1:41] size, shall we say, and more often a
[1:43] whole room size. Um,
[1:46] packed with
[1:48] fans and false floors and all like that,
[1:51] big huge things that we would worship.
[1:53] All right, so
[1:55] people started connecting more and more
[1:56] of them with the ARPANET and at some
[1:59] point they said, "Well, we got to keep
[2:00] track, so we're going to give them
[2:01] names." When I came on the scene, it was
[2:04] pretty established practice that what
[2:07] you would do is you would have a
[2:08] computer file
[2:10] that was maintained by an organization
[2:12] called the SRI NIC
[2:15] and that file would list a machine name
[2:19] and basically its internet address.
[2:23] Um
[2:24] and so that file, at the time I started
[2:27] playing with computers, was probably 50
[2:31] lines long.
[2:32] And when I started doing the DNS, it was
[2:34] maybe a couple hundred lines long. The
[2:36] problem you have is if you want to scale
[2:39] at all,
[2:41] what you really need to do is first of
[2:43] all,
[2:44] if you want to add a new computer, what
[2:47] you would do is you would call up SRI,
[2:49] say, "Hey, I want to add a line to that
[2:51] file." Okay, and hopefully you were
[2:55] calling during 9:00 to 5:00 Pacific time
[2:58] cuz that's the only time they would
[2:59] answer the phone.
[3:01] So, they'd add it to that file. Now,
[3:03] that file was kind of like the master
[3:07] copy of a phone book and the only way
[3:09] you would become known is when other
[3:11] people on the network would say, "Hey,
[3:13] give me an updated copy of who's who."
[3:17] So, it relied upon the fact that you
[3:19] would call up SRI, you would get into
[3:21] the new version of the file, and you
[3:23] would become known as people
[3:26] took a copy of that file from SRI.
[3:30] Uh so, that was the basic scheme uh that
[3:33] was around.
[3:34] Uh I had been doing research on
[3:37] uh some other performance measurement
[3:40] issues, but frankly, I hated it because
[3:43] there were all these famous guys that
[3:44] were doing the same stuff. So, I wasn't
[3:47] going to get anywhere doing that. Um so,
[3:50] this, you know, what could you do next
[3:53] was a nice little research problem that
[3:55] they could hand off to me.
[3:57] People now say, "Well, Paul, how'd you
[3:59] get this wonderful big job designing the
[4:01] DNS?" Nobody thought it was that
[4:03] important. It was a nice little problem,
[4:06] you know, go away. And also they didn't
[4:08] monitor me that much. They cuz they
[4:11] probably would have guided me to be
[4:13] doing something sort of less.
[4:16] Well, I had done naming stuff in my
[4:18] prior career at UC Irvine.
[4:22] And I had also done
[4:24] multiple machine kind of stuff when I
[4:27] was an undergraduate at MIT
[4:29] uh with the architecture machine people,
[4:32] which went on to become the Media Lab.
[4:35] Okay. Uh but they were poor at the time
[4:38] and unknown, not like the flashy thing
[4:40] they are today.
[4:42] So they had multiple machines that they
[4:45] needed to connect. So I had always been
[4:46] working with multiple machines and
[4:49] distributed systems. And I had done a
[4:51] bad job with designing a new naming
[4:54] system for the UC Irvine people.
[4:57] So there was a bunch of mistakes that I
[4:59] didn't make over again.
[5:01] And there was a bunch of mistakes that I
[5:02] thought other people had made with some
[5:04] other work
[5:05] that had gone like Xerox Park and so
[5:08] forth.
[5:09] So to
[5:11] I would say at least 50% the the whole
[5:14] design idea wasn't based upon the
[5:16] Internet community or USC ISI where I
[5:19] was working. It was just based upon I
[5:22] had now done it wrong a couple of times.
[5:25] Okay, this time I was going to get it
[5:26] right. And this was in fact a much
[5:29] larger audience.
[5:30] My idea was it might have to scale up to
[5:34] 10 million or so different um
[5:37] identities.
[5:39] Um and so that's how it got started.
[5:42] Now
[5:44] the thing that was, I think, really
[5:46] important that people didn't realize.
[5:48] People realize the business about
[5:50] distributing the management, which it
[5:51] did.
[5:52] You only had to like call up once and
[5:54] then you could do all your computers
[5:56] yourself thereafter.
[5:58] Okay, and the information always
[6:00] propagated. It wasn't like it would only
[6:02] propagate when somebody else got a copy
[6:04] of the phone book. It would be instantly
[6:06] available.
[6:09] That helped a lot in that era.
[6:11] But the other thing was that it always
[6:14] had the idea that there were more than
[6:16] machine names.
[6:18] Okay? I mean, people say, "Well, the
[6:20] first application was this business
[6:22] about translating a host name, a
[6:25] computer name,
[6:27] to an IP address." That, you know,
[6:28] 192.168.1.0
[6:31] or whatever.
[6:32] Um
[6:33] but in reality
[6:35] the first thing it did is it said,
[6:38] "Oh, we have to figure out which name
[6:40] server we have to ask in order to find
[6:42] this information."
[6:44] That was the first question that ever
[6:46] got asked by the DNS. Not a Not Don't
[6:48] find me an address. It's like find me
[6:50] the place where I look up this name.
[6:53] So, DNS used its own
[6:57] system to keep track of where all this
[6:59] data was.
[7:00] So, the magic, if you will, came in two
[7:02] parts, one of which is you could divide
[7:05] up the space and give individuals
[7:07] control indefinitely. You know, today
[7:10] you have millions of separate
[7:12] organizations that own their own little
[7:15] chunk of the name space. But the other
[7:16] part of the magic is it looks like it's
[7:19] all together.
[7:21] Right? You don't say, "Oh my god, this
[7:23] is going to be hard. This name ends in
[7:25] .fr, it's in France. This is going to be
[7:28] hard." Nope.
[7:29] You just go, "Oh, it ends in .fr. Okay."
[7:32] >> You mentioned in some of your early
[7:34] naming work you had made a lot of
[7:35] mistakes that you fixed in the original
[7:39] design of DNS. What kind of mistakes did
[7:42] you make?
[7:43] >> For example, when at the architecture
[7:45] machine, I was designing this
[7:47] uh file system where people could have
[7:50] file names,
[7:52] but they would be accessing them from
[7:54] different computers. Um
[7:57] and I said, "Okay, well, what we'll do
[8:00] is we'll let you have a name, and then
[8:02] you can group that into a directory."
[8:05] So, it was kind of like you had a
[8:06] two-level name, you know, there was a
[8:07] most significant part and the least
[8:09] significant part. Two-level names. Xerox
[8:12] PARC
[8:13] at the time I was designing the DNS had
[8:15] their own kind of system, and they had
[8:17] fixed three levels. And I said, "This is
[8:20] stupid. Okay, I'm just going to design
[8:22] it so that you can nest it however many
[8:24] levels you want." Um because
[8:28] people want to or be have freedom to
[8:30] organize their information. And you
[8:33] might say, "Well, mostly people use like
[8:35] three levels or four levels,
[8:37] but there are lots of hidden
[8:40] applications where they go
[8:43] many, many, many levels deep. And it it
[8:46] just it doesn't make any sense. If
[8:49] you're going to go to the trouble to
[8:51] allow people to nest
[8:54] names, you should just say, "Okay,
[8:57] any any reasonable amount of nesting,
[9:00] that'll work." That's one example.
[9:02] >> Why is it that a URL goes from
[9:06] most specific to least specific? So, I'm
[9:09] talking about if you go to, I don't
[9:12] know, maps.google.com,
[9:15] com's the
[9:16] biggest one, Google's the more specific,
[9:19] maps is the most specific. And then
[9:21] after that, there's a the path, which is
[9:24] that's like a file directory, so it gets
[9:26] more and more specific as you go. Why is
[9:28] it inverted like that?
[9:32] >> You say inverted, I say it's an obvious
[9:34] choice. Think about this. Okay, when
[9:37] you're typing in a URL, if I type maps,
[9:41] it can probably guess
[9:43] the google.com. If I type in com, is it
[9:46] going to address google.maps? No.
[9:49] So, the point is is that what you want
[9:50] to do is to put put in the part. So, if
[9:54] the machine is going to complete it, it
[9:56] has a chance. Right? Obviously, start
[9:59] with com. You go, "Okay, well, that
[10:01] narrows it down to 260 million different
[10:04] names." Right? [laughter]
[10:05] Whereas, if what you do is you type oh,
[10:08] I don't know, you know, you happen to
[10:09] have a machine called Alice. It may be
[10:12] able to say, "Oh, okay, I'll look what's
[10:14] around locally." And so, that's why the
[10:16] order is the way it is. And I make no
[10:18] apologies. And there's a lot of people
[10:19] that think I was wrong.
[10:22] >> What about the dub dub dub in the
[10:24] beginning? Cuz that
[10:26] I could go www.
[10:29] maps.google.com, and that www feels like
[10:33] a very generic thing. It seems to just
[10:35] be prepended to
[10:37] a lot of URLs. What What is that, and
[10:39] why is it there?
[10:40] >> Well, you know, what happened was that
[10:43] there was different things like there
[10:44] was email, uh and there was what was
[10:47] called file transfer protocol, and uh
[10:51] there was also,
[10:52] you know, the web.
[10:54] So, the idea was that if you had an
[10:57] identity, let's say we're talking about
[10:59] Stanford.
[11:00] Stanford has stanford.edu.
[11:03] Okay, well, they get to create names
[11:06] under that. And what we're going to do
[11:08] is we're going to say, as a convention,
[11:10] if you want to talk to the web server
[11:12] for Stanford, you put a www in front of
[11:15] stanford.edu. You want to talk to the
[11:18] web server at whitehouse.gov, well, you
[11:21] go www.whitehouse.gov.
[11:23] Now, it turns out that now pretty much
[11:25] all people do is talk to web servers,
[11:28] right?
[11:29] Um I mean, it turns out that that whole
[11:31] idea about separate machines and that
[11:34] you would have ftp.stanford.edu
[11:37] or whatever, all that kind of died out.
[11:40] People will uh
[11:42] made
[11:43] a lot of different choices and you know,
[11:45] I always say what I did for the DNS is I
[11:48] built the sub-basement and the basement
[11:51] and the two floors of this building. And
[11:54] then people came along and added a
[11:56] hundred different things. You know, so
[11:58] different floors. It's a little bit
[12:01] like, you know, sort of Gaudi's
[12:02] cathedral, right? In Barcelona. It kind
[12:04] of like there's a bunch of strange
[12:06] shapes. But seeing as everybody did it,
[12:08] it's kind of worse than that cuz there's
[12:10] been over a hundred different additions
[12:12] that have been proposed on the basic
[12:14] system.
[12:15] And you know, I have to tell you that
[12:17] probably about half of them are less
[12:19] than average from a standpoint of
[12:21] quality. So it's a bunch of ideas that
[12:24] failed. There's a bunch of ideas that um
[12:29] you know, didn't turn out the way people
[12:31] thought. Um you know, people had a lot
[12:34] of different dreams. One of the things
[12:36] they said was
[12:37] all right, well, this is great. We're
[12:39] going to use the DNS to route phone
[12:42] calls.
[12:43] So these people got together and
[12:46] you know, did a bunch of stuff, but it
[12:48] turns out that they didn't pay attention
[12:51] to what were the features that people
[12:53] wanted out of their phone system that
[12:55] you don't think about. Like the fact
[12:57] that 800 numbers aren't the same
[12:59] everywhere. That kind of mechanism
[13:02] didn't get uh added by the internet
[13:05] geniuses. So for that reason, the system
[13:09] that they designed wasn't as good
[13:10] functionally as the one that was already
[13:13] in place.
[13:14] So there was a certain amount of
[13:16] pushback there. And uh you know, one of
[13:18] the things that's kind of interesting is
[13:20] people go, oh god, it's terrible. You
[13:23] know, all these domain names now are
[13:25] getting sold. And they get sold for big
[13:27] numbers, and the name I want I can't
[13:29] get, and
[13:30] you know, blah blah blah.
[13:32] Well, it turns out that that pretty much
[13:35] has happened with every numbering system
[13:38] that has ever been created. For example,
[13:41] you know, you've seen the barcode on the
[13:42] back of your
[13:44] uh whatever you bought today at the
[13:46] market, right?
[13:47] Barcodes started out as a US thing,
[13:51] where it was basically a 10-digit code.
[13:54] All right.
[13:55] And there was an organization if you
[13:57] came along and you said, "Okay, I need,
[14:00] you know,
[14:01] a block of 5,000 codes." They would
[14:03] allocate it to you and then sell it to
[14:05] you. So, the Europeans said, "Oh, well,
[14:07] we want in on this."
[14:09] And uh
[14:11] They said, "Well, that's great, you
[14:12] know, cuz you're going to have to buy a
[14:14] lot. We'll take a lot of money from
[14:15] you." They said, "No, no, we don't want
[14:17] We shouldn't have to pay for this."
[14:19] And so, what they did is they made an
[14:20] 11-digit code,
[14:23] where they embedded the 10 digits of US
[14:25] codes, I don't know, probably with the
[14:27] with the thing that starts with zero,
[14:29] and then they said, "Well, okay, and
[14:31] we'll give away the rest of the name
[14:32] space."
[14:33] All right.
[14:35] And so, then airlines came to them and
[14:37] said, "Oh, this is great, you know, give
[14:39] us some numbers,
[14:41] you know, so that we can keep track of
[14:42] passengers' bags."
[14:44] And they said, "Okay, well, you're ready
[14:46] to pay, right? Cuz we're going to charge
[14:47] you."
[14:49] You know, so it's
[14:51] once people start to own some of these
[14:54] name and number spaces, they of course,
[14:57] you know, they have to manage it, and
[14:59] that costs some money, but the idea of
[15:01] making a profit out of it is uh
[15:03] always front and center. But, I mean,
[15:05] the other thing that happened with the
[15:07] DNS is
[15:08] uh
[15:09] I created the original specs, and they
[15:11] were first published in 1983.
[15:15] And by 1986, the system was kind of up
[15:17] and running. And
[15:20] 1986 was the first year where somebody
[15:23] actually [clears throat] configured a
[15:25] computer system that only did the DNS
[15:27] and didn't have any of that old host
[15:29] table thing.
[15:31] Just didn't have it. Wasn't necessary.
[15:33] Um, you know, there was a whole
[15:35] transition process there where you know,
[15:38] I would go and get a copy of the host
[15:41] table from SRI every day and I would
[15:44] immediately put it into the DNS. So, the
[15:46] DNS always had all of the information
[15:49] that they had
[15:50] plus any of the pioneers that joined and
[15:53] cut their own domains and started adding
[15:55] stuff.
[15:56] So, the the DNS over time got had
[15:59] everything that the host table had, but
[16:02] uh also had other places that you
[16:04] couldn't reach via the host table. Uh,
[16:07] so it was pretty much inevitable that if
[16:11] we could keep it running reliably enough
[16:13] and give enough performance, which
[16:15] people were incredibly skeptical about
[16:17] cuz they said, "Okay. So, either there's
[16:20] the scheme where I get a copy of this
[16:22] table and when I want to know
[16:23] information, I look it up or I go off
[16:26] and send queries across the internet and
[16:28] see whether or not the right answer
[16:30] comes back. Which one sounds more
[16:32] reliable?"
[16:33] >> How does DNS work in terms of like the
[16:36] high-level technical pieces?
[16:38] >> If you think about the name space being
[16:41] written as a big tree,
[16:42] you know, where there's the first level,
[16:45] the so-called top-level domains like
[16:48] .com and .us and so forth. And then
[16:51] there's a tree structure that grows
[16:52] underneath them. We talked before about
[16:54] how well, the names were structured one
[16:57] way in order you can do the auto
[16:59] complete. Well, it turns out you go the
[17:01] other direction when you're trying to
[17:02] actually locate the server for a name.
[17:05] Cuz what you do is you say, "Okay, we
[17:08] have this thing called the root, which
[17:11] is really the node that's on top. It's
[17:13] the real top-level domain and there's
[17:15] only one of them."
[17:16] So, what you can always do is you can
[17:18] ask the root. You can say,
[17:20] "Where is stanford.edu?"
[17:22] And the root says, "Well, sorry Paul, I
[17:25] don't know, but I know where edu is. I
[17:28] know where a server for edu is, so I'll
[17:30] point you at that. Go ask that." So,
[17:33] then when you go ask that, it says,
[17:34] "Okay,
[17:35] um I could I know about stanford.edu."
[17:39] So,
[17:41] you search
[17:42] in order to find the the correct name
[17:44] server in the opposite direction from if
[17:47] you will from autocomplete. But
[17:49] basically, if you think of the it all
[17:51] being organized as a tree structure, you
[17:53] know, internet
[17:55] trees and computer science trees are
[17:57] always kind of like the root is up at
[17:58] the top and then the leaves are down at
[18:00] the you know, the
[18:02] We can't help ourselves. And anyway, it
[18:04] says that if you
[18:05] we if you can get to the top, you can
[18:08] always go down one level.
[18:10] Okay?
[18:11] Each time you ask a server that's
[18:13] responsible for a particular set of
[18:15] names, it can tell you about one level
[18:17] down in that name.
[18:19] So, if you can get to the top, you can
[18:21] always go to the bottom.
[18:23] And so, there's a little bit of
[18:24] configuration that usually exists that's
[18:27] manually configured in a name server
[18:30] that tells you where the root servers
[18:32] are.
[18:33] The root servers back way back when used
[18:35] to be some number of machines. When the
[18:38] system first came operational, there was
[18:41] three of them.
[18:43] Today, there's 13 different clouds of
[18:45] servers
[18:47] for the root.
[18:48] >> How did you convince yourself that
[18:50] performance wouldn't be an issue if you
[18:52] had to do all these recursive calls?
[18:54] >> Well, there's there's another thing that
[18:56] happens here
[18:57] um that we haven't talked about. When
[19:00] you go and look up something like you
[19:02] say, "Okay, where is the web server
[19:05] um for uci.edu, for UC Irvine's?"
[19:10] Uh
[19:11] when you get back the answer for that,
[19:13] it comes with a timestamp on it that
[19:16] says, "Okay,
[19:18] you can assume this doesn't change for
[19:20] some number of seconds." Okay? And what
[19:23] people often would do is for things that
[19:26] don't change very often, what they would
[19:27] do is they'd have say, "Okay, you can
[19:29] keep that information for a day."
[19:31] So, there's
[19:34] this caching infrastructure such that if
[19:37] you get it, you don't have to look it up
[19:39] again for a day. Okay? It's a little bit
[19:43] like the way you manage your
[19:44] refrigerator, right? You go in there and
[19:45] you go, "Uh milk, you know, best if used
[19:48] in a week." Oh, you know, you go in your
[19:50] pantry, canned beans, best if used this
[19:53] century, you know? I mean, there there
[19:55] basically the information
[19:57] uh
[19:58] is all timestamped like that so that you
[20:01] can know how long you can keep it. So,
[20:04] the idea is that yeah, you might have to
[20:08] go and fetch this information across the
[20:11] network, but once you have it, if you
[20:13] use it again, and a lot of this
[20:15] information gets used over and over and
[20:17] over again, right? Um
[20:21] then you only pay the cost
[20:23] one out of many many many accesses.
[20:27] >> Well, so I guess the big question in my
[20:28] mind is how did you convince people that
[20:31] performance and reliability would be
[20:33] acceptable?
[20:34] >> Well, you know, basically what happened
[20:36] was every morning I would get a copy of
[20:39] the the existing standard, and I would
[20:42] pump all those names into the DNS. So,
[20:45] they would all So, if you were accessing
[20:47] the DNS, you could always access all of
[20:50] the the current stuff in the host table.
[20:53] And um
[20:56] then there were people that wanted to
[20:57] manage their own stuff, and they were
[21:00] they were hip and they were cool, so
[21:01] they used the DNS, and they added stuff
[21:04] into the DNS. They didn't bother to
[21:05] update the host table.
[21:07] So, there would be this community that
[21:09] would grow that you know, weren't
[21:12] playing the old game cuz they knew that
[21:14] they could play both games by just doing
[21:16] that if they did the DNS, they got both
[21:18] name spaces, if you will.
[21:21] And if they just relied on the host
[21:22] table, well, there were some places they
[21:25] weren't going to go. And that's where
[21:26] the cool kids hang hung out.
[21:28] Um
[21:30] and you know, the the other thing that's
[21:32] kind of amusing is that in the early
[21:34] days of the internet the SRI Nick was
[21:36] three people.
[21:38] Okay?
[21:40] But as
[21:42] the internet expanded and people were
[21:44] calling up to get names added they
[21:46] started to have more people they had to
[21:48] answer the phone.
[21:50] And the DOD was paying for this. And
[21:53] they're kind of going like, "Well, why
[21:54] are we paying to register stanford.edu's
[21:57] machines one by one? And and you know,
[22:01] as the NSFnet expanded and things
[22:04] weren't all run by
[22:06] the ARPA or or the DDN
[22:09] um they said, "Why are we going to do
[22:11] this?" Cuz they eventually had like 20
[22:13] people on staff just dealing with
[22:15] maintaining this stuff.
[22:17] And they said, "Well, no. How about we
[22:20] just pay it for maintaining it for our
[22:22] own people?" And so that's when people
[22:25] started thinking about splitting off,
[22:27] you may have heard of the Milnet.
[22:28] Anyway, that was sort of a network that
[22:31] was going to be used for real military
[22:33] stuff. And why are we going to do that?
[22:35] Uh
[22:36] it's kind of funny because, you know,
[22:38] the sponsorship of the DNS research also
[22:41] uh came along
[22:43] like in the late 1980s, they were kind
[22:45] of going ARPA in particular
[22:48] who sponsored the early work
[22:50] said, "Paul, this isn't research
[22:52] anymore. It's all done deal. It was a
[22:54] great thing, but it's not new and super
[22:57] wizzy and innovative and so forth. So
[23:00] we're not going to pay you anymore for
[23:02] that. And I had sent them a a proposal
[23:06] for what I thought was the next level of
[23:08] the DNS, and they said, "Nah, nah,
[23:10] that's not
[23:11] that's not like cutting-edge research
[23:13] All this DNS stuff, that's old." I sent
[23:15] in a proposal to NSF,
[23:18] and I said, "Okay, here's what I want to
[23:20] do. I I think what we can do is we can
[23:23] use the DNS not only to keep track of
[23:25] the names of everything,
[23:27] but we can use it to build an index of
[23:29] all the content that's out there. You
[23:31] know, who has Who has files of what?"
[23:35] And so I wrote up a proposal, and I sent
[23:36] it to NSF.
[23:38] And they said, "Paul, you're crazy.
[23:39] There's like thousands of machines. You
[23:41] can't possibly keep up with all of that,
[23:44] okay?"
[23:45] So this is where Paul made one of his
[23:47] fundamental errors. You say, "Why didn't
[23:48] you register 10,000 names and go to a
[23:50] beach and wait for them to all be worth
[23:52] a million dollars?"
[23:54] >> Do you ever think about that you could
[23:56] have owned those things?
[23:57] >> Well, you know, you could have mined
[23:59] Bitcoin in your younger days, and
[24:02] right?
[24:04] >> [laughter]
[24:04] >> That's fair.
[24:05] >> Yeah. Yeah.
[24:06] Yeah, you you you had a 286 laptop could
[24:09] have made mined a few billion dollars'
[24:12] worth of Bitcoin without much trouble,
[24:14] right?
[24:15] >> OpenAI, [snorts] Anthropic, and Cursor
[24:17] all use this product to make their lives
[24:19] easier. WorkOS is an API platform that
[24:22] adds enterprise features like SSO, SCIM,
[24:24] and RBAC to your app. These are things
[24:26] that you need to sell to other
[24:27] companies, but aren't the main focus of
[24:29] what you're building. And now they've
[24:31] added more support for AI agents. For
[24:33] instance, auth for agents gives each
[24:35] agent its own identity with short-lived
[24:38] scope tokens instead of a long-lived API
[24:40] key. So if something goes wrong, you can
[24:42] revoke one session, and everything under
[24:43] it dies. Another feature they have is
[24:45] Airlock, which is an authorization
[24:47] layer. Every action agent takes is
[24:49] checked against rules that you can write
[24:51] in plain English. So it's not
[24:53] rubber-stamping everything, and it's not
[24:55] running unsupervised, either. And
[24:57] lastly, they have pipes, which connects
[24:58] your agents to over 300 third-party
[25:00] tools without you ever needing to manage
[25:02] a token. So, if you're building SaaS or
[25:05] AI agents and selling to enterprises,
[25:07] WorkOS fills all these gaps in a few
[25:09] lines of code. Check them out at
[25:11] workos.com to learn more and get
[25:13] started, and I appreciate them for
[25:15] sponsoring my show.
[25:17] >> You mentioned [snorts] those those root
[25:19] servers that we go to initially.
[25:21] What's the economic incentive or who's
[25:24] paying for those servers? What's the
[25:25] economic incentive for those 13 clouds
[25:28] that exist?
[25:29] >> I asked myself this question a lot.
[25:32] And I have to tell you it's one of the
[25:34] things I don't quite understand.
[25:36] Um
[25:38] you know,
[25:39] the first thing that happened
[25:42] where I didn't have somebody come to me,
[25:44] I mean, I I went around saying, "Hey,
[25:46] will you run a root server? I'll give
[25:48] you the code, you know, blah blah blah."
[25:50] cuz I was trying to get my And then one
[25:52] day the Europeans walked in and said,
[25:54] "We need a European root server."
[25:56] >> [laughter]
[25:58] >> And today, I'm not sure why. I mean,
[26:00] they certainly there's certainly
[26:02] prestige involved, and there's
[26:06] um
[26:08] a move to centralize the DNS.
[26:11] So, more and more of the DNS is being
[26:14] sub- subsumed by some of the
[26:16] hyperscalers,
[26:18] like Cloudflare, Google, and so forth.
[26:21] Um so, the system is getting less
[26:23] distributed than it was. Uh early In the
[26:25] early days, it was very distributed. Um
[26:30] now it's centralized and more and more
[26:32] so.
[26:33] Part of that is is that over time, as
[26:35] people added more and more stuff in
[26:37] there, it got more and more complicated
[26:39] to run.
[26:41] Um
[26:42] you know, there's this big discussion
[26:45] that us the internet old boys have. They
[26:47] go, "You know, it's got it's hard to run
[26:49] an email server these days." In the old
[26:51] days it used to be
[26:53] easy.
[26:55] So,
[26:56] people want to outsource the operation
[26:58] of a lot of stuff and not deal with it.
[27:02] And people do complicated load balancing
[27:05] tricks.
[27:06] There's a certain
[27:08] urge to outsource because there's only a
[27:09] limited number of people that really
[27:11] want to deal with the inner complexity.
[27:14] Um but
[27:16] there's a lot of people that would you
[27:18] know, say there's there's got to be a
[27:21] conspiracy theory here. The big
[27:23] companies,
[27:25] you know, they claim that they don't
[27:26] collect data there. Okay, they claim
[27:28] that they don't collect data there.
[27:30] Um and I would never, you know,
[27:33] I would never accuse them of trying to
[27:35] make a profit. I'm so Well, never mind.
[27:37] Um
[27:39] you know, it it it's kind of funny
[27:40] because uh one of the things people do
[27:43] is they talk about how the internet
[27:45] um it's a dangerous privacy
[27:48] risk in the internet.
[27:51] Now,
[27:54] it's really in a way kind of silly cuz
[27:56] given the way that ad networks
[27:58] and um
[28:01] big websites operate,
[28:03] um
[28:04] the
[28:05] DNS may be a privacy
[28:08] risk, but
[28:09] your privacy gets violated in so much
[28:13] more effective ways by all of this web
[28:15] stuff.
[28:16] You know, it's like it doesn't make it
[28:18] to the metal round of privacy invasion.
[28:21] I mean, you know, you take a look at the
[28:22] way ad networks work.
[28:25] Um
[28:26] you know, most people don't realize that
[28:29] when an ad gets populated on their
[28:32] webpage,
[28:33] 150 or more organizations have been
[28:37] asked, "Do you want to serve this ad to
[28:39] this person?"
[28:41] They don't identify the person, but they
[28:43] can identify up to 144 characteristics
[28:47] of the person.
[28:48] So,
[28:50] I appreciate the people who have done
[28:51] some stuff about DNS privacy.
[28:54] Uh but
[28:57] your privacy is is is long gone by the
[29:00] time you worry about this.
[29:02] >> I mean, if you're running a big cloud
[29:05] service to do DNS at a hyper scalar like
[29:09] Amazon or something like that, that's
[29:11] going to cost a good amount of money.
[29:12] So, I I would think
[29:14] there's something more than prestige as
[29:17] an incentive.
[29:18] >> Well, sure. I mean, I can suggest a
[29:20] couple of things, one of which is that
[29:23] Microsoft, for example, knows how the
[29:26] performance of LinkedIn affects how much
[29:28] money they make.
[29:29] Basically, the faster it works, the more
[29:31] money they make.
[29:32] So,
[29:33] they want to give you a good response
[29:35] time.
[29:36] All right. So, there are people that
[29:38] just want to accelerate the operations
[29:41] in the network. And they may feel that
[29:44] if they
[29:46] take it over, they can make it run
[29:48] faster, and they'll make more money. And
[29:50] so, I guess that's a win-win.
[29:52] Uh I don't think that's all there is to
[29:54] it, but, you know, I'll tell you a funny
[29:56] story.
[29:58] In the early days of the DNS, you know,
[30:00] after the Europeans got their first root
[30:02] server and so forth,
[30:05] France, Sweden,
[30:07] various other countries
[30:09] all had very long processes if you want
[30:12] to register a domain name. So, although
[30:14] we had given them control of everything
[30:17] under .fr,
[30:19] after that, it was up to them to make
[30:21] whatever process they wanted. And so,
[30:23] they, you know, they they they said,
[30:25] "Well, you know, we have to have a
[30:26] deposit. You have to fill out this
[30:27] form." We make it very complicated.
[30:30] All right. So,
[30:32] along comes a quaintance, a guy I got to
[30:36] meet,
[30:37] and he goes to the island of Niue.
[30:40] The island of Niue? It's in the South
[30:42] Pacific. Okay.
[30:45] And because
[30:47] the Germans
[30:48] gave them a country code of .nu
[30:52] they got to have their own top-level
[30:53] domain.
[30:55] So, the guy goes to Niue and says, "Hey,
[30:58] I'll make you a deal.
[31:01] I'll run the Niue top-level domain for
[31:03] you.
[31:04] And um
[31:06] I'll give you a cut."
[31:08] There's arguments about exactly what the
[31:10] cut was supposed to be and whether or
[31:11] not he actually paid it and on and on
[31:13] and on.
[31:14] But basically, he started reg- he
[31:16] started registering names, and he would
[31:18] go to
[31:20] websites and so forth
[31:22] in particular France and Sweden and say,
[31:25] "Hi, if you want a domain name,
[31:27] you know, give me 10 kroners and you can
[31:30] have any name
[31:32] that's not in use.
[31:34] You know?
[31:35] I'm just I charge you per name and, you
[31:38] know, because I charge you per name, I'm
[31:40] going to make this easy because I want
[31:41] more people to register names."
[31:44] So, he starts registering a whole bunch
[31:46] of people in Sweden and France because
[31:48] .nu translates to
[31:52] new or cool or
[31:55] nude.
[31:56] But maybe people don't care about that.
[31:58] At any rate, um
[32:00] so, he starts registering tens of
[32:02] thousands of names. And all these people
[32:05] who okay, they want they want their own
[32:08] domain. They
[32:09] And they're they're in France and the
[32:11] French government is making it tough.
[32:13] Well, register under Niue.
[32:15] And it's kind of hip and cool.
[32:18] Um
[32:19] and so, eventually So, he starts
[32:21] registering all of these people.
[32:23] Um eventually, it gets shut down. And
[32:27] Sweden was given control of Niue because
[32:32] they said it was a national security
[32:36] uh issue for Sweden cuz so many Swedes
[32:39] were registered under
[32:41] .nu that they had to make sure that
[32:43] their
[32:44] stuff would continue to operate.
[32:46] There was kind of some
[32:48] supposed stories about uh you know, .nu
[32:52] and so forth.
[32:53] But this kind of happened, okay?
[32:56] So, do you know why Anguilla is very
[32:59] lucky?
[33:00] >> .ai
[33:01] >> .ai Right?
[33:03] >> Right.
[33:04] >> [laughter]
[33:04] >> You know, Columbia .co can't get a .com?
[33:08] Well, you can get a .co. [laughter]
[33:10] It's close.
[33:11] Um so, you know, this is another one of
[33:13] these ownership of the name space and
[33:15] and so forth.
[33:17] >> When I was reading about I guess some of
[33:20] the history of this work, there's all
[33:22] these RFCs and my high-level
[33:25] understanding is that's a name for an
[33:27] engineering proposal.
[33:29] And I'm
[33:30] curious to know what's the the culture
[33:33] behind an RFC?
[33:35] >> Well, that's evolved over time. In the
[33:37] good old days, people would you know, I
[33:39] would write this RFC for example as the
[33:42] two beginning RFCs for the DNS.
[33:45] So, I wrote them
[33:47] um and my boss happened to be the guy
[33:49] that hands out the RFC numbers. So, he
[33:52] would give me a number and then he would
[33:53] publish it.
[33:55] Um and that just meant putting it on a
[33:57] server somewhere and people would come
[33:59] along and pluck these RFCs down. Um
[34:04] in time though,
[34:06] you know,
[34:07] people started having meetings and
[34:09] organizing the IETF.
[34:12] And so, now we have a bunch of process.
[34:14] And we have different kinds of RFCs.
[34:17] Some are just informational. You can
[34:19] write an article and this is what I
[34:22] think and if it's like reasonably
[34:24] cogent, you know, you can probably get
[34:26] an RFC number for it. And you know,
[34:29] um
[34:30] but then there's standards track stuff
[34:33] that are going to be internet they're
[34:34] going to be standards and they're, you
[34:37] know, politics and paperwork and
[34:39] you know, there's a whole lot of
[34:40] process.
[34:42] Um you know, the
[34:44] uh the IET the IETF takes credit for
[34:47] DNS. They
[34:48] Okay. Now, one of the problems with that
[34:51] is that the DNS spec came out in 1983
[34:55] and the first meeting of the IETF was in
[34:57] 1986.
[34:59] So, um
[35:02] yeah, there's a
[35:03] How do you How exactly do you explain
[35:05] it?
[35:06] >> Today, computers are ubiquitous and it's
[35:10] being talked about in social media all
[35:11] the time. But back then, I think it was
[35:13] a lot more niche. So, how did you get
[35:15] into computing?
[35:17] >> MIT
[35:18] was offering some summer classes for
[35:21] high school students and I just took one
[35:22] and I was kind of fascinated. But I was
[35:24] a physics major. I was I was, you know,
[35:27] physics won World War and it was just
[35:30] cool and, you know, blah blah blah,
[35:32] right? Um
[35:34] So, I got to MIT. I was a physics major.
[35:37] Um you know, it's like one of the places
[35:40] where you expected to have big change.
[35:43] You know, nuclear power was going to be
[35:44] too cheap to meter.
[35:46] Uh that was one of the slogans. You
[35:48] know, nuclear reactors didn't turn out
[35:50] to be particularly cheap.
[35:52] And physics has its beauty, you know, I
[35:54] mean, all right, but I wanted to get a
[35:57] little bit of extra money.
[35:58] So, my two choices were working in the
[36:01] food service industry
[36:04] or I could get a job as a beginning
[36:06] programmer. Paid better than food
[36:08] service, at least to start.
[36:10] But I said, "No, I think I'll do this
[36:11] computer stuff."
[36:12] And one thing led to another.
[36:14] Um
[36:15] and then
[36:17] somewhere around my junior year,
[36:21] uh I'd been working at IBM. I'd been
[36:23] working at the
[36:25] what became the Media Lab. I had been
[36:27] working at Draper Lab. I I'd done a
[36:28] bunch of
[36:30] little computer jobs. Um, and I was
[36:33] getting paid much more than a food
[36:35] service worker. It was good. Um, and my
[36:38] physics advisor
[36:40] uh, and the head of the IBM Cambridge
[36:42] Scientific Center
[36:44] had a lunch where they decided they
[36:46] should do an intervention on me and tell
[36:48] me, "Paul, you're not a very good
[36:50] physicist, but you seem to do really
[36:52] well with this computer stuff.
[36:55] Why don't you change careers and as a
[36:59] to make it easier because we understand
[37:01] some of your
[37:03] goal-line mentality stuff,
[37:06] we'll agree to give you the physics
[37:07] degree.
[37:08] It's only a a learner's permit anyway.
[37:11] It's just a bachelor's degree. And and
[37:13] we'll figure out how to have you double
[37:14] major and get a computer science degree.
[37:17] And why don't you just go off and kind
[37:19] of do what you're good at?" Um, so
[37:21] that's how I got started and that's how,
[37:25] you know, it all went. Um,
[37:28] I mean, it turned out that
[37:31] a bunch of the stuff that we did
[37:33] at uh, the architecture department at
[37:36] MIT was cutting-edge computer science at
[37:39] the time.
[37:41] You can go and, you know, what we did is
[37:43] because people would only give us mini
[37:45] computers because, well, we weren't very
[37:48] important and so forth and so on. Well,
[37:50] we figured out how to network them
[37:52] together and do stuff where we would
[37:54] share. And you know, at Carnegie Mellon,
[37:57] they had an ARPA-funded project to do
[37:59] pretty much that. Figure out how to put
[38:01] together a bunch of mini computers and
[38:04] and and do distributed work. Um, it sort
[38:07] of sounds a little bit like the cloud,
[38:09] right? Um, so it was cutting-edge
[38:11] research, but we just did it because,
[38:13] well, we were
[38:14] doing what we what we could.
[38:17] >> When you're working on DNS and you're
[38:18] seeing the internet growing,
[38:20] did you ever think it would grow as big
[38:23] as it is today or I'm kind of curious to
[38:26] view it from the lens of like right now,
[38:30] if you look at
[38:31] the headlines, it's AI is kind of
[38:34] exploding and it's, you know, the this
[38:36] future thing.
[38:38] And at the time, if you were to look at
[38:40] the headlines when the internet was
[38:41] growing, was it a similar type of
[38:44] uh
[38:45] environment, I guess, that where the
[38:47] internet was
[38:48] this, you know, huge thing?
[38:51] >> I you know, I mean, I kind of grew up in
[38:53] the core of the internet, so that I kind
[38:54] of understood it as it was growing.
[38:57] Um
[38:58] you know, the AI thing, I don't have
[39:01] nearly the same,
[39:03] you know, feeling of
[39:05] intuition
[39:06] uh
[39:07] on it, so that it doesn't feel the same
[39:10] to me at all. Um you know,
[39:13] oddly enough,
[39:15] this is like the second or third coming
[39:18] of AI.
[39:19] In the sense that I remember in 1985,
[39:23] um
[39:24] they had this big AI conference in so in
[39:27] Southern California over Marina del Rey,
[39:30] and AI was all hot and it was going to
[39:32] take off, and then it disappeared.
[39:35] Um
[39:36] and you know, the research agencies and
[39:39] ARPA in particular
[39:41] had had a couple of different things,
[39:43] projects, where they had said, "If only
[39:46] we could make like more powerful
[39:48] computer or groups of computers,
[39:51] then we can actually kind of do some of
[39:53] this AI stuff." Cuz they,
[39:55] you know, and AI has kind of this
[39:57] history, right? Remember when,
[39:59] you know, can Do you think you can teach
[40:01] a computer to play chess? Maybe you're
[40:02] too young for that, but, you know, once
[40:04] upon a time, having computer play chess
[40:07] was kind of like AI, right? And in
[40:10] reality, it was if you have a big enough
[40:12] hammer, you you can make
[40:15] a chess-playing machine.
[40:17] Um and a bunch of what happened
[40:19] particularly
[40:21] with early stuff about uh
[40:24] being able to understand speech
[40:26] was people figured out how to put
[40:28] together a big enough database and have
[40:31] enough processing power
[40:33] that a bunch of it was done by brute
[40:35] force. And a lot of it is these large
[40:38] language models. Uh you know, there's
[40:41] there's a bunch of brute force behind
[40:42] the screen.
[40:43] People talk about "Oh, G will figure out
[40:45] how to do it clever." But um
[40:48] you know, there's there's an awful lot
[40:51] of what AI is doing is trial and error.
[40:55] And it just does trial and error on a
[40:57] huge scale. It can do more errors and
[41:00] more trials than you can imagine. Um
[41:04] but it gets results.
[41:06] Um so it's a different kind of thing cuz
[41:09] you do need to have a pretty big machine
[41:12] to do anything interesting.
[41:14] Whereas like I said, you know, we did
[41:16] interesting things for the time
[41:19] back at the architecture machine group
[41:22] with with mini computers.
[41:24] Um it was kind of funny because I also
[41:26] had a day job but I didn't have a day
[41:28] job, but I had a part-time job at IBM
[41:31] where they had the biggest machine
[41:34] you know, that IBM made basically there.
[41:36] Um and I could use it as much as I
[41:38] wanted. It's very strange to
[41:41] cuz everybody else was like, "Well, we
[41:43] got to give you a small amount of time
[41:45] and if you use that up, we're not sure
[41:46] we can give you more."
[41:48] IBM would give me as much as I wanted.
[41:50] Um
[41:52] you know, and in particular they were
[41:53] having me do things that used an awful
[41:55] lot of machine time.
[41:57] So in some sense I kind of time traveled
[42:00] uh
[42:01] because I never had a scarcity of
[42:05] machine time. I always had somebody that
[42:08] wanted to give me as much as I could as
[42:10] I could eat. Um nowadays everybody has
[42:13] it, but um it was sort of a little bit
[42:16] different for my career. I think one of
[42:18] the things, you know, the mistakes that
[42:20] I made
[42:21] were all characterized by not doing
[42:26] sufficient
[42:28] understanding about things at the edge.
[42:31] Like when I talk to college students and
[42:33] give them advice,
[42:34] I say very often you can find
[42:36] opportunity where kind of two fields
[42:39] come together.
[42:40] Um, so for example,
[42:43] once upon a time biology had nothing to
[42:46] do with computers. Now, it's all biology
[42:49] and computers, right? Um you know, I had
[42:53] once upon a time I got a a a consulting
[42:56] job because I could both speak physics
[42:59] to the physics majors and I could
[43:02] program computers. So, DEC was trying to
[43:05] build
[43:06] They wouldn't tell me that they were DEC
[43:07] for a long time. Hello. Wasn't hard to
[43:10] figure out. But, um
[43:13] you know, they they
[43:15] they tested me. They said, "Well, we
[43:17] hear that you can both program and talk
[43:19] to device physicists. Is that true?"
[43:23] I said, "Yes, I speak both languages."
[43:24] [laughter]
[43:26] And they gave me a little test. But, you
[43:29] know, often times there's opportunity
[43:31] where two things come together, two
[43:33] fields come together. Um and so one of
[43:36] the things that says is that you should
[43:38] always be looking for something that's a
[43:40] little bit beyond the edge of whatever
[43:43] field you're currently in. Because maybe
[43:45] you can find something else that touches
[43:47] it. Sort of like doing reconnaissance.
[43:50] So, you know, when I had my index
[43:52] proposal
[43:54] and ARPA and NSF said, "This isn't
[43:57] research." If I had been smart enough to
[44:00] know that, well, the people at Sand Hill
[44:02] Road might fund me to go start a company
[44:04] there.
[44:06] Um
[44:07] I mean, that happened many times. I
[44:09] think I had
[44:11] at least half a dozen different times
[44:13] where I could have started a company if
[44:14] only I knew that well, all you have to
[44:17] do to start a company is, you know, you
[44:19] you don't have to understand how to keep
[44:20] books. There are people for that and
[44:22] then blah blah blah. All you need to do
[44:24] is to figure out how to go to Sand Hill
[44:27] Road
[44:28] or the equivalent and and ask for money.
[44:32] Um I've done that several times.
[44:35] Um
[44:37] and um
[44:39] you know, it's its own strange view.
[44:42] Once upon a time
[44:44] you've heard of the SoftBank?
[44:46] >> Yeah.
[44:46] >> Yeah. Once upon a time I had the
[44:50] privilege of introducing SoftBank to its
[44:53] biggest failure.
[44:54] Um it was a company called Urban Media.
[44:57] And uh I went to them with a pitch
[45:00] about, "Hi, we want to go deploy this
[45:02] system
[45:04] in three cities and scale it up if it
[45:06] works."
[45:08] And they said, "No.
[45:09] Think big or go home. Um you'll have to
[45:12] do it in all and this is the way they
[45:14] put it.
[45:15] All of the NFL cities and LA."
[45:19] So, you know, rather than starting off
[45:21] with a budget of 5 million, they they
[45:24] they insisted we started off with a bit
[45:26] with a budget of like 50. And we
[45:29] eventually burned through 100 million,
[45:31] which was big money at the time.
[45:33] Um probably more than that actually. But
[45:36] um
[45:38] you know, it's kind of funny to the way
[45:40] those guys think and the way they work.
[45:42] Um so, you know, if
[45:46] if I could understand Sand Hill Road,
[45:48] um I probably would have started many
[45:51] businesses.
[45:52] I don't know why I didn't. Um
[45:55] but you know, you you you find
[45:58] you know, students who say, "Well, I
[46:00] don't
[46:01] I don't want to
[46:03] you know,
[46:04] deal with business.
[46:06] Well, but you need to understand enough
[46:08] about business so that if you want to
[46:09] start one, you can figure out, yeah,
[46:11] okay, I need an accountant.
[46:13] Yeah, I know lots of people in in in
[46:16] startups hate sales people. They hate
[46:17] marketing people. Yeah, but you need
[46:20] them, you know.
[46:21] So,
[46:23] um understanding how things work and you
[46:26] know, kind of doing your reconnaissance
[46:28] and particularly looking for something
[46:30] that combines something that you know
[46:32] with something else
[46:34] where there's leverage.
[46:35] Um there's a lot of ways that I think
[46:37] you can find opportunity.
[46:39] >> When you look back on your whole career
[46:41] and all the experience that you have, if
[46:43] you could go back and give yourself some
[46:45] advice knowing what you know today, what
[46:48] would you say?
[46:49] >> I should have paid more attention in
[46:51] French class back in high school.
[46:53] Cuz French class in high school was the
[46:55] one thing I loathed.
[46:58] Uh my teachers were insane. They were
[47:00] all of these World War I vets who were
[47:04] we would say today PS- PTSD, in those
[47:07] days we said shell shock.
[47:09] But they were like they were just like
[47:10] crazy. Like they we I had one French
[47:13] teacher who was also my homeroom teacher
[47:15] and
[47:16] he ate Jell-O and potato chips with a
[47:17] fork and knife.
[47:21] Okay. You know, so I just hated the I
[47:23] just
[47:24] didn't do French. I just
[47:27] Um and then I ended up living in France
[47:29] for eight years. Okay. I probably should
[47:31] have paid more attention way back when.
[47:33] How do you tell if knowledge is useful?
[47:36] Well, all knowledge I think is useful.
[47:38] It's just a question about whether or
[47:39] not you're going to get a chance to
[47:41] apply it.
[47:42] And you don't really know.
[47:44] Um so, why not be a sponge?
[47:48] Um and I think
[47:50] get a little bit out of your comfort
[47:51] zone. You know, and then there's the
[47:53] whole business about vesting
[47:56] and uh qualified small business shares
[47:59] and
[48:01] the way that all works. And Silicon
[48:03] Valley pretty much screws the peons and
[48:07] rewards the VCs. And the only difference
[48:10] is a kind of a lack of knowledge.
[48:13] Um
[48:15] I had one company that
[48:17] that I was in and so we're getting
[48:20] bought.
[48:21] And so okay. Um
[48:25] And I said, "Okay, great. So um you
[48:27] know, one of the things I want to do is
[48:29] to make sure that the employees
[48:31] understand about you know, 1202
[48:34] qualified small business and and the way
[48:36] they can handle the taxes here
[48:39] um to make their life good." The people
[48:41] buying us said, "No.
[48:44] You're absolutely forbidden from doing
[48:45] that." Why?
[48:47] They just don't want people rocking the
[48:49] boat, I guess.
[48:50] Um you know, the other thing is is that
[48:53] sometimes, I mean
[48:55] it was it was kind of funny because I
[48:57] was just a director on the company, but
[48:59] I had bought into series A and uh I had
[49:03] a bunch of NSOs
[49:05] and um some of which were I had
[49:07] exercised, so I had shares and some of
[49:10] which you know, I I I I just had
[49:13] unexercised options and then there were
[49:15] some things where
[49:16] you know, when they buy you, you lose
[49:18] whatever is invested.
[49:21] And the tax rates on those were just
[49:23] incredibly different. Well, it turns out
[49:25] that if you had qualified small business
[49:28] stock basically what you can do is an
[49:32] 83(b) says that rather than having
[49:34] options that you exercise when they're
[49:36] vested
[49:37] they give you the options and you can
[49:40] exercise them immediately.
[49:42] Okay?
[49:43] But they can buy the stock back if you
[49:46] leave if they want to. All right. But
[49:49] the point is is that you buy it at
[49:50] whatever the price is then.
[49:52] So, if the price of the common is say a
[49:55] penny a share then,
[49:56] all right, you buy it and all of it is
[50:00] established with a base of a penny a
[50:01] share.
[50:02] Whereas, if you do have the option, the
[50:05] company does well, the stock price goes
[50:07] up to 10 cents and you have to exercise
[50:09] it, you have to pay 9 cents of
[50:12] capital gains there and then then.
[50:14] All right.
[50:16] The detail in all of this was that I was
[50:19] paying long-term capital gains on my
[50:22] on my series A investment.
[50:25] I was paying zero federal taxes on the
[50:29] common
[50:30] that I got and had vested in 83(b).
[50:34] Um
[50:35] and then the
[50:37] exercisable
[50:39] part of it got taxed at
[50:41] 65%. I mean, some absurd rate.
[50:45] I mean, in California taxes at all, they
[50:46] don't care.
[50:48] Anyway,
[50:49] the the VCs,
[50:51] they know all this stuff.
[50:54] Uh
[50:54] but I would I would wager that probably
[50:59] oh, I don't know, 50% of people
[51:02] um
[51:04] are paying more taxes than they have to
[51:05] because they don't know about this and
[51:07] they can't
[51:08] get the information. Cuz to qualify, you
[51:11] have to show that the company had
[51:13] was below a certain financial level and
[51:16] it wasn't of a prescribed type. Like,
[51:19] you can't do this with a real estate
[51:21] company, investment company. Um and it
[51:24] has to be some percentage US citizens.
[51:27] Uh
[51:28] and it varies a little bit over time,
[51:30] but basically that's it. And you get a
[51:32] reduced tax rate.
[51:33] My most recent role, I said, "Okay,
[51:36] I I want you you to, you know, give me
[51:39] the information. I want a list of
[51:41] employees and their citizenship."
[51:43] >> [laughter]
[51:44] >> Okay, and I want to know how much
[51:46] capitalization we have. Okay? And I just
[51:48] want to get these in a formal way so
[51:51] that when the time comes I'll know how
[51:52] to handle the taxes. Um and I really cut
[51:56] back to the story of the company being
[51:57] sold. Um
[52:00] we eventually
[52:02] we agreed not to give
[52:04] our employees
[52:06] tax advice. Okay?
[52:09] We did give them the list of founding
[52:11] employees and what their citizenship
[52:13] was. And we
[52:15] and we did, you know,
[52:17] um
[52:18] give them, you know, this other thing
[52:20] and we said that this, you know, you
[52:22] probably want to go read 1202, by the
[52:24] way.
[52:25] Um
[52:26] and uh I'm not sure how many of them
[52:29] did.
[52:30] Uh because, you know,
[52:32] I had a number of different chains on
[52:35] me. I was barely able to squeak this out
[52:37] through the door, but you know,
[52:40] Silicon Valley, there's a hierarchy
[52:42] there.
[52:43] And it isn't like everybody gets the
[52:47] entrepreneurial spirit and everybody
[52:48] gets
[52:49] the same
[52:51] privileges.
[52:53] >> Awesome. Well, thank you so much for
[52:55] your time. I really appreciate it, Paul.
[52:57] >> Hey, thank you for watching this
[52:58] podcast. If you liked it and you want to
[53:00] see the show grow, please support with a
[53:02] comment or a like.
[53:04] Also, if you have any recommendations
[53:06] for people you want me to bring on,
[53:08] please drop a comment. Guests like
[53:10] Barbara Liskov, Mike Stonebraker, Mark
[53:13] Brooker, these were all people that I
[53:15] brought on because someone left a
[53:17] comment. On another note, aside from the
[53:19] podcast, I'm working on building the
[53:21] ergonomic keyboard that I wish existed.
[53:23] Here's a glance at the prototype. It's a
[53:25] split keyboard, so there's two sides. Um
[53:28] this is in the case. But yeah, we
[53:30] launched on Kickstarter and we hit our
[53:32] goal within 8 hours of launching. I
[53:34] really appreciate it if you were one of
[53:35] the people who grabbed one of the early
[53:37] units. Um we're now working on the long
[53:39] journey of building the tooling now. And
[53:41] so if you still want to pick one up,
[53:43] I've left the late pledges open on
[53:45] Kickstarter, so you can grab one there.
[53:47] I'll put a link in the description.
[53:49] Thank you again for watching the
[53:51] podcast, and I'll see you in the next
[53:53] episode.