Ryan Peterman · Ryan Peterman · Transcript & summary by WhipScribe
The engineer who designed DNS explains its key choices, from name order to caching, and what he thinks went wrong since.
Tap a chapter to open that moment in the transcript; the link to it is copied for you.
“Nobody thought it was that important. It was a nice little problem, go away.” Paul Mockapetris · at 3:59 — open in the transcript →
“And I make no apologies. And there's a lot of people that think I was wrong.” Paul Mockapetris · at 10:17 — open in the transcript →
Paul Mockapetris designed the Domain Name System in the early 1980s, when every networked computer was listed in a single file kept by the SRI NIC and new entries meant phoning SRI during California office hours. The design rested on two ideas: hand each organisation permanent control of its own slice of the namespace, while making the whole thing look like one seamless directory, with DNS even using itself to find which server holds a given name. Earlier naming systems he had built at MIT and UC Irvine, plus Xerox PARC's fixed three-level scheme, taught him to allow any depth of nesting and to order names so local completion works.
Adoption came from running both worlds at once. Mockapetris loaded the SRI host table into DNS every morning, so early adopters who registered their own domains could reach everything, and caching with expiry timers answered the skeptics who doubted that network lookups could be fast or reliable. He is blunt about what came later: more than 100 proposed extensions, many of middling quality, a drift toward hyperscalers such as Cloudflare and Google running the system, and root-server economics he admits he does not fully understand. He also argues that DNS privacy matters little next to ad networks that profile visitors on every page.
The rest of the conversation is career and money. Mockapetris switched from physics to computing after his MIT advisor and an IBM lab head staged an intervention, regrets not learning how venture funding works, recalls SoftBank pushing one of his ventures into a $100 million burn, and explains how qualified small business stock and 83(b) elections can cut startup employees' taxes.
Paul Mockapetris created the Domain Name System while at USC ISI, publishing the first DNS specifications in 1983. He studied physics and computer science at MIT and later worked as a startup director and investor.
Paul Mockapetris rejects the idea that names like maps.google.com are backwards. Putting the most specific label first lets a computer guess the rest: typing a local machine name can be completed from nearby context, while starting with .com narrows things only to hundreds of millions of names. He told Ryan Peterman he makes no apologies for the choice, though many people think he got it wrong.
Paul Mockapetris says every host was listed in a single text file maintained by the SRI NIC, mapping machine names to addresses. Adding a computer meant phoning SRI, ideally during Pacific business hours, and a new machine only became known as other sites downloaded fresh copies of that file. It was about 50 lines when he started with computers and a couple of hundred lines when he began designing DNS around 1982.
Paul Mockapetris describes the namespace as a tree with a single root. A resolver asks the root where a name like stanford.edu lives; the root points to the .edu servers, which point to Stanford's. Every answer carries a time-to-live, so stable records can be kept for a day and the network cost is paid once across many lookups. He compares it to expiry dates on milk versus canned beans.
Paul Mockapetris admits he does not fully understand the incentive. Early on he went around asking organisations to run root servers, until European operators asked for one of their own. Today he points to prestige and to companies like Microsoft that earn more when services such as LinkedIn respond faster, and he notes DNS is becoming more centralised under hyperscalers like Cloudflare and Google because running it has grown complicated.
Paul Mockapetris says DNS may leak some information, but it barely registers next to how ad networks and large websites track people. He describes ad auctions where 150 or more organisations are asked whether they want to serve an ad to a visitor, identified by up to 144 characteristics rather than by name. He appreciates DNS privacy work but argues most users' privacy is already gone before DNS comes into it.
Paul Mockapetris recalls that countries such as France and Sweden made registering under their own country codes slow and bureaucratic. An acquaintance offered to run the .nu domain for the Pacific island of Niue in exchange for a cut, then sold names cheaply per registration to customers in Sweden and France, signing up tens of thousands. The operation was eventually shut down and Sweden took control of .nu, citing national security because so many Swedes depended on it.
Paul Mockapetris says that by the late 1980s ARPA told him DNS was a done deal and no longer research, so it would stop paying for it. He then proposed to NSF using DNS to build an index of what content every machine held, and was told the idea was crazy because there were thousands of machines. Looking back, he says he never realised he could have taken such ideas to Sand Hill Road investors instead.
Paul Mockapetris says many startup employees pay more tax than necessary because they do not know about Section 1202 qualified small business stock or 83(b) elections, which let you exercise early at a low price. In one acquisition he paid long-term rates on his Series A shares and zero federal tax on early-exercised common, while unexercised options were taxed at around 65%. The buyer barred the company from giving employees tax advice, so he passed on citizenship and capitalisation records and told them to read 1202.
Our own transcript of the public episode, with a timestamp about every 90 seconds. Tap a timestamp or the link button on a paragraph to copy a link that opens this page there.
0:00I make no apologies, and there's a lot of people that think I was wrong. This is Paul Makopetras, who created the Domain Name System, or DNS, and I interviewed him for the stories behind its creation. Nobody thought it was that important. It was a nice little problem, you know, go away. Xerox PARC, at the time I was designing the DNS, had their own kind of system, and I said, this is stupid. You say inverted. I say it's an obvious choice. Think about this. Those root servers, who's paying for those servers? What's the economic incentive? Silicon Valley pretty much screws the peons and rewards the VCs. The only difference is... Here's the full episode. You know, before we talk about DNS getting created,
0:46I'd like to go over what was computing like before DNS? Well, it depends on where, how far before DNS. You know, but just to put a post in the ground, I started thinking about DNS probably in 1982. Now, to backspace over that, the ARPANET was created in the late 60s. So computers were being connected. So that meant that there would be more than one computer on the network. Obviously, if you only have a computer in a big lab, you don't need to name it unless you feel like it because it isn't like which computer do you want to talk to is ever an issue. When you start networking together, then the question comes up which computer do you want to talk to is ever an issue? When we start networking together then the question comes up
1:27How do you decide which one you want to talk to from whichever one you happen to be at? Because in these days the computers we're talking about were big machines You know at least refrigerator size shall we say and more often a whole room size Packed with at least refrigerator size, shall we say, and more often a whole room size, packed with fans and false floors and all like that, big, huge things that we would worship. All right, so people started connecting more and more of them with the ARPANET. And at some point they said, well, we've got to keep track, so we're going to give them names. When I came on the scene it was pretty established practice that what you would do is you would have a computer file that was maintained by an
2:12organization called the SRI NIC and that file would list a machine name and basically its internet address. And so that file, at the time I started playing with computers, was probably 50 lines long. And when I started doing the DNS, it was maybe a couple hundred lines long. The problem you have is, if you want to scale at all, what you really need to do is, first of all, if you wanted to add a new computer, what you would do is you would call up SRI, say, hey, I want to add a line to that file. Okay. And hopefully, you were calling during nine to five Pacific time, because that's the only time they would answer the phone. So they'd add it to that file. Now, that file was kind of like the master copy of a phone book.
3:08And the only way you would become known is when other people on the network would say, hey, get me an updated copy of who's who. So it relied upon the fact that you would call up SRI, you would get into the new version of the file, and you would become known as people took a copy of that file from SRI. So that was the basic scheme that was around. I had been doing research on some other performance measurement issues, but frankly, I hated it because there were all these famous guys that were doing the same stuff. So I wasn't going to get anywhere doing that. So this, you know, what could you do next was a nice little research problem that they could hand off to me. People now say, well, Paul,
3:59how'd you get this wonderful big job designing the DNS? Nobody thought it was that important. It was a nice little problem, go away. And also, they didn't monitor me that much because they probably would have guided me to be doing something sort of less. Well, I had done naming stuff in my prior career at UC Irvine. And I had also done multiple machine kind of stuff when I was an undergraduate at MIT with the architecture machine people, which went on to become the Media Lab. But they were poor at the time and unknown, not like the flashy thing they are today. So they had multiple machines that they needed to connect. So I had always been working with multiple machines and distributed systems.
4:51And I had done a bad job with designing a new naming system for the UC Irvine people. So there was a bunch of mistakes that I didn't make over again. And there was a bunch of mistakes that I thought other people had made with some other work that had gone on like Xerox PARC and so forth. So, I would say at least 50% the whole design idea wasn't based upon the internet community or USC ISI where I was working. 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. And this was, in fact, a much larger audience. My idea was it might have to scale up to 10 million or so different identities. And so that's how it got started. Now, the thing that was, I think, really important
5:47that people didn't realize, people realize the business about distributing the management, which you did. You only had to call up once, and then you could do all your computers yourself thereafter. And the information always propagated. It wasn't like it would only propagate when somebody else got a copy of the phone book. It would be instantly available. That helped a lot in that era. But the other thing was that it always had the idea that there were more than machine names. I mean, people say, well, the first application was this business about translating a host name or computer name to an IP address, that 192.168.1.0 or whatever. But in reality, the first thing it did is it said, oh, we have to figure out which name server we have to ask in order to find this information.
6:44That was the first question that ever got asked by the DNS. Don't find me an address. It's like, find me the place where I look up this name. So DNS used its own system to keep track of where all this data was. So the magic, if you will, came in two parts, one of which is you could divide up the space and give individuals control indefinitely. Today you have millions of separate organizations that own their own little chunk of the namespace. But the other part of the magic is it looks like it's all together, right? You don't say, oh my god, this is going to be hard. This name ends in .fr. It's in God, this is going to be hard. This name ends in dot FR. It's in France. This is going to be hard. Nope. Just go as an FR. Okay. You mentioned in some of
7:33your early naming work, you had made a lot of mistakes that you fixed in the original design of DNS. What kind of mistakes did you make? For example, when at the architecture machine, I was designing this file system where people could have file names, but they would be accessing them from different computers. And I said, okay, well, what we'll do is we'll let you have a name and then you can group that into a directory. So it was kind of like you had a two-level name. It was the most significant part and the least significant part, two-level names. 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. OK, I'm just going to design it so that you can nest it however many levels you want.
8:26Because people want to have freedom to organize their information. And you might say, well, mostly people use like three levels or four levels. But there are lots of hidden applications where they go many, many, many levels deep. And it just doesn't make any sense. If you're going to go to the trouble to allow people to nest names, you should just say, okay, any reasonable amount of nesting, that'll work. That's one example. Why is it that URL goes from most specific to least specific? So I'm talking about if you go to, I don't know, maps.google.com. Com's the biggest one. Google's the more specific. Maps is the most specific. And then after that, there's the path, which is like a file directory.
9:26So it gets more and more specific as you go. Why is it inverted like that? You say inverted. I say it's an obvious choice. Think about this. OK, when you're typing in a URL, if I type maps, it can probably guess the google.com. If I type in com, is it going to address google.com if I type in calm is it gonna address google.com? No, so the point is is that what you want to do is to? Put put in the part. So if the machine is going to complete it it has a chance right obviously start with calm you go Okay, well that narrows it down to 260 million different names, right? Whereas if what you do is you type, oh, I don't know, you know, you happen to have a machine called Alice, it may be able to say, oh, okay, I'll look what's around locally.
10:15And so that's why the order is the way it is. And I make no apologies. And there's a lot of people that think I was wrong. What about the www in the beginning? Because I could go www.maps.google.com and that www feels like a very generic thing or it seems to just be propended to a lot of URLs. What is that and why is it there? Well, what happened was that there was different things like there was email, there was what was called file transfer protocol, and there was also the web. So the idea was that if you had an identity, let's say we're talking about Stanford. Stanford has stanford.edu. OK, well, they get to create names under that. And what we're going to do is we're going to say, as a convention, if you want to talk
11:11to the web server for Stanford, you put a www in front of stanford.edu. If you want to talk to the web server at whitehouse.gov, well, you go www.whitehouse.gov. Now, it turns out that now pretty much all people do is talk to web servers. It turns out that that whole idea about separate machines and that you would have ftp.stanford.edu or whatever, all that died out. People made a lot of different choices. And I always say what I did for the DNS is I built the sub-basement and the basement, the two floors of this building. And then people came along and added 100 different things, different floors. It's a little bit like sort of Gaudi's Cathedral, right, in Barcelona. It's a bunch of strange shapes.
12:07But seeing as everybody did it, it's worse than that because there's been over 100 different editions that have been proposed on the basic system. And I have to tell you that probably about half of them are less than average from a standpoint of quality. So it's a bunch of ideas that failed. There's a bunch of ideas that, you know, didn't turn out the way people thought. You know, people had a lot of different dreams. One of the things they said was, all right, well, this is great. We're going to use the DNS to route phone calls. So these people got together and did a bunch of stuff. But it turns out that they didn't pay attention to what were the features that people wanted out of their phone system that you don't think about, like the fact that 800 numbers aren't
12:59the same everywhere. That kind of mechanism didn't get added by the internet geniuses. So for that reason, the system that they designed wasn't as good functionally as the one that was already in place. So there was a certain amount of pushback there. And one of the things that's kind of interesting is people go, oh, god, it's terrible. All these domain names now are getting sold. And they get sold for big numbers. And the name I want, I can't get. And blah, blah, blah. Well, it turns out that that pretty much has happened with every numbering system that has ever been created. For example, you've seen the barcode on the back of whatever you bought today at the market, right? Barcode started out as a US thing where it was basically a 10-digit code.
13:54All right. And there was an organization. And if you came along and you said, OK, I need a block of 5,000 codes, they would allocate it to you and then sell it to you. So the Europeans said, oh, well, we want in on this. And they said, well, that's great, you know, because you're going to have to buy a lot. We'll take a lot of money from you. They said, no, no, we don't. We shouldn't have to pay for this. And so what they did is they made an 11-digit code where they embedded the 10 digits of US codes, I don't know, probably with the thing that starts with zero. And then they said, well, OK, we'll give away the rest of the namespace. And so then airlines came to them and said, oh, this is great.
14:39Give us some numbers so that we can keep track of passengers' bags. And they said, OK, well, you're ready to pay, right, because we're going to charge you. So once people start to own some of these name and number spaces, they, of course, they have to manage it. And that costs some money. But the idea of making a profit out of it is always front and center. I mean, the other thing that happened with the DNS is I created the original specs. They were first published in 1983. And by 1986, the system was kind of up and running. And 1986 was the first year where somebody actually configured a computer system that only did the DNS and didn't have any of that old host table thing. Just didn't have it.
15:32Wasn't necessary. There was a whole transition process there where I would go and get a copy of the host table from SRI every day. And I would immediately put it into the DNS. The DNS always had all the information that they had, plus any of the pioneers that joined and got their own domains and started adding stuff. The DNS over time had everything that the host table had, but also had other places that you couldn't reach via the host table had, but also had other places that you couldn't reach via the host table. So it was pretty much inevitable that if we could keep it running reliably enough and give enough performance, which people were incredibly skeptical about because they said, OK, so either there's this scheme where I get a copy of this table and when I want to
16:23know 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? How does DNS work in terms of the high level technical pieces? If you think about the namespace being written as a big tree, where there's the first level, the so-called top level domains like .com and .us and so forth. And then there's a tree structure that grows underneath them. We talked before about how, well, the names were structured one way in order you can do the autocomplete. Well, it turns out you go the other direction when you're trying to actually locate the server for a name. Because what you do is you say, OK, we have this thing called the root, which is really the node that's on top.
17:13It's the real top level domain. And there's only one of them. So what you can always do is you can ask the root. You can say, where is Stanford.edu? And the root says, well, sorry, Paul, I don't know. But I know where edu is. I know where a server for edu is. So I'll point you at that. Go ask that. So then when you go ask that, it says, OK, I know about stanford.edu. So you search in order to find the correct name server in the opposite direction from, if you will, from autocomplete. But basically, if you think of it all being organized as a tree structure, internet trees and computer science trees are always kind of like the roots up at the top and then the leaves are down at the bottom. We can't help ourselves.
18:03At any rate, it says that if you can get to the top, you can always go down one level. Each time you ask a server that's responsible for a particular set of names, it can tell you about one level down in that name. If you can get to the top, you can always go to the bottom. There's a little bit of configuration that usually exists that's manually configured in a name server that tells you where the root servers are. The root servers way back when used to be some number of machines. When the system first came operational, there was three of them. Today there's 13 different clouds of servers for the route. How did you convince yourself that performance wouldn't be an issue if you had to do all these
18:53recursive calls? Well there's another thing that happens here that we haven't talked about. When you go and look up something like you say okay, OK, where is the web server for UCI.edu, for UC Irvine's? When you get back the answer for that, it comes with a timestamp on it that says, OK, you could assume this doesn't change for some number of seconds. OK. doesn't change for some number of seconds. What people often would do is for things that don't change very often, what they would do is they'd say, OK, you can keep that information for a day. So there's this caching infrastructure such that if you get it, you don't have to look it up again for a day. It's a little bit like the way you manage your refrigerator. You go in there and you go, milk, best if used in a day. Okay? It's a little bit like the way you manage your refrigerator, right? You go in there and you go, milk, you know, best if used in a week. Oh, you
19:50know, you go in your pantry, canned beans, best of use this century. You know, I mean, they're basically the information is all time stamped like that so that you can know how long you can keep it. So the idea is that, yeah, you might have to go and fetch this information across the network. But once you have it, if you use it again, and a lot of this information gets used over and over and over again, then you only pay the cost one out of many, many, many accesses. Well, so I guess the big question in my mind is, how did you convince people that performance and reliability would be acceptable? Well, you know, basically what happened was, every morning I would get a copy of the existing standard,
20:41and I would pump all of those names into the DNS. So if you were accessing the DNS, you could always access all of the current stuff in the host table. And then there were people that wanted to manage their own stuff. And they were hip and they were cool. So they used the DNS and they added stuff into the DNS. They didn't bother to update the host table. They were hip and they were cool. So they used the DNS and they added stuff into the DNS. They didn't bother to update the host table. So there would be this community that would grow that, you know, weren't playing the old game. Because they knew that they could play both games by just doing – if they did the DNS, they got both namespaces, if you will.
21:25And if they just relied on the host table, well, there were some places they weren't going to go. And that's where the cool kids hung out. And the other thing that's kind of amusing is that in the early days of the internet, the SRI neck was three people. But as the internet expanded and people were calling up to get names added, they started to have more people to answer the phone. And the DOD was paying for this. And they're kind of going like, well, why are we going to do this? Because they eventually had like 20 people on staff just dealing with maintaining this stuff. And they said, well, no. How about we just pay for maintaining it for our own people? And so that's when people started thinking about splitting off.
22:27You may have heard of the mill net. At any rate, that was sort of a network that was going to be used for real military stuff. And why are we going to do that? It's kind of funny because the sponsorship of the DNS research also came along. Like in the late 1980s, they were kind were going ARPA in particular, who sponsored the early work. Said, Paul, this isn't research anymore. It's all done deal. It was a great thing, but it's not new and super whizzy and innovative and so forth. So we're not going to pay you anymore for that. And I had sent them a proposal for what I thought was the next level of the DNS. They said, no, no, that's not like cutting edge research. All this DNS stuff, that's old.
23:15I sent in a proposal to NSF. I said, OK, here's what I want to do. I think what we can do is we can use the DNS not only to keep track of the names of everything, but we can use it to build an index of all the content that's out there. Who has files of what? I wrote up a proposal and I sent it to NSF. They said, Paul, you're crazy. There's like thousands of machines. You can't possibly keep up with all of that. This is where Paul made one of his fundamental errors. like thousands of machines. You can't possibly keep up with all of that. Okay? So this is where Paul made one of his fundamental errors. He said, why didn't you register 10,000 names and go to a beach and wait for them to all be worth a million dollars?
23:54Do you ever think about that you could have owned those things? Well, you know, you could have mined Bitcoin in your younger days, right? That's fair. You had a 286 laptop could have mined a few billion dollars worth of Bitcoin without much trouble, right? OpenAI, Anthropic and Cursor all use this product to make their lives easier. WorkOS is an API platform that adds enterprise features like SSO, Skim and RBAC to your app. These are things that you need to sell to other companies, but aren't the main focus of what you're building. And now they've added more support for AI agents. For instance, Auth for Agents gives each agent its own identity with short-lived scope tokens instead of a long-lived API key.
24:41So if something goes wrong, you can revoke one session and everything under it dies. Another feature they have is Airlock, which is an authorization layer. Every action agent takes is checked against rules that you can write in plain English. So it's not rubber stamping everything and it's not running unsupervised either. And lastly, they have Pipes, which connects your agents to over 300 third-party tools without you ever needing to manage a token. So if you're building SaaS or AI agents and selling to enterprises, WorkOS fills all these gaps in a few lines of code. Check them out at workos.com to learn more and get started. And I appreciate them for sponsoring my show. You mentioned those root servers that we go to initially.
25:21What's the economic incentive? Who's paying for those servers? What's the economic incentive for those 13 clouds that exist? I ask myself this question a lot. And I have to tell you, it's one of the things I don't quite understand. You know, the first thing that happened where I didn't have somebody come to me, I mean, I went around saying, hey, will you run a root server? I'll give you the code, you know, blah, blah, blah, because I was trying to get, and then one day the Europeans walked in and said, we need a European root server. And today, I'm not sure why. I mean, there's certainly prestige involved and there's a move to centralize the DNS. So more and more of the DNS is being subsumed by some of the hyperscalers like Cloudflare,
26:19Google and so forth. So the system is getting less distributed than it was. In the early days, it was very distributed. Now it's centralized, more and more so. Part of that is that over time, as people added more and more stuff in there, it got more and more complicated to run. There's this big discussion that us internet old boys have. They go, it's hard to run an email server these days. In the old days, it used to be easy. So people want to outsource the operation of a lot of stuff and not deal with it. And people do complicated load balancing tricks. There's a certain urge to outsource, because there's only a limited number of people that really want to deal with the inner complexity. But there's a lot of people that would say,
27:19there's got to be a conspiracy theory here. The big companies, they claim that they don't collect data there. And I would never accuse them of trying to make a profit. Well, never mind. It's kind of funny because one of the things people do is they talk about how the internet, it's a dangerous privacy risk in the internet. Now, it's really, in a way, kind of silly because given the way that ad networks and big websites operate, the 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. I mean, you know, you take a look at the way ad networks work. You know,
28:27most people don't realize that when an ad gets populated on their web page, 150 or more organizations have been asked, do you want to serve this ad to this person? They don't identify the person, but they can identify up to 144 characteristics of the person. So I appreciate the people who have done some stuff about DNS privacy, but your privacy is long gone by the time you worry about this. I mean, if you're running a big cloud service to do DNS at a hyperscaler like Amazon or something like that, that's going to cost a good amount of money. So I would think there's something more than prestige as an incentive. Well, sure. I mean, I can suggest a couple of things. One of which is that Microsoft, for example,
29:24knows how the performance of LinkedIn affects how much money they make. Basically, the faster it works, the more money they make. So they want to give you a good response time. So there are people that just want to accelerate the operations in the network. And they may feel that if they take it over, they can make it run faster, and they will make more money. And so I guess that's a win-win. I don't think that's all there is to it. But I'll tell you a funny story. In the early days of the DNS, after the Europeans got their first root server and so forth, France, Sweden, various other countries, all had very long processes if you want to register a domain name. So although we had given them control of everything under .fr, after that, it was up to them to
30:21make whatever process they wanted. And so they said, know, they said, well, you know, we have to have a deposit. You have to fill out this form. We'll make it very complicated. All right. So along comes an acquaintance, a guy I got to meet, and he goes to the island of Niue. The island of Niue? It's in the South Pacific. Because the Germans gave them a country code of .nu, they got to have their own top-level domain. And so the guy goes to Niue and says, hey, I'll make you a deal. I'll run the Niue top-level domain for you, and I'll give you a cut. There's arguments about exactly what the cut was supposed to be and whether or not he actually paid it and on and on and on. But basically, he started registering names,
31:18and he would go to websites and so forth, in particular France and Sweden, and say, hi, if you want a domain name, give me 10 kronors and you can have any name that's not in use. I charge you per name and because I charge you per name, I'm going to make this easy because I want more people to register names. So he starts registering a whole bunch of people in Sweden and France because .edu translates to new or cool or nude, but maybe people don't care about that. At any rate, um, so he starts registering tens of thousands of names and And all these people who, OK, they want their own domain. And they're in France. And the French government is making it tough. Eh, we'll register under a new way.
32:15And it's kind of hip and cool. And so he starts registering all of these people. Eventually, it gets shut down. And Sweden was given control of New Way because they said it was a national security issue for Sweden because so many Swedes were registered under .nu that they had to make sure that their stuff would continue to operate. There was kind of some supposed stories about .NU and so forth, but this kind of happened. Okay. So do you know why Anguilla is very lucky? .AI. .AI. Right? Right. You know, Columbia, dot CO. Can't get a dot com? Well, you can get a dot CO. It's close. So, you know, this is another one of these ownership of the namespace and so forth. When I was reading about, I guess, some of the history of this work, there's all these RFCs.
33:24And my high level understanding is that's a name for an engineering proposal. I'm curious to know, what's the culture behind an RFC? Well, that's evolved over time. In the good old days, people would, I would write this RFC, for example, there's the two beginning RFCs for the DNS. So I wrote them. And my boss happened to be the guy that hands out the RFC numbers. So he would give me a number and then he would publish it. And that just meant putting it on a server somewhere and people will come along and pluck these RFCs down. In time, though, you know, people started having meetings and organizing the IETF. And so now we have a bunch of process. And we have different kinds of RFCs. Some are just informational. You can write an article. And this is what I think.
34:22And if it's like reasonably cogent, you can probably get an RFC number for it. But then there's standards track stuff that are going to be standards and there, politics and paperwork, there's a whole lot of process. The IETF takes credit for DNS. Okay. 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. So, you know, how exactly do you explain it? Today, computers are ubiquitous, and it's being talked about on social media all the time. But back then, I think it was a lot more niche. So how did you get into computing? MIT was offering some summer classes for high school students, and I just took one, and I was kind of fascinated.
35:24But I was a physics major. I was, you know, physics won World War II and it was just cool and, you know, blah, blah, blah, right? So I got to MIT. I was a physics major. You know, it's like one of the places where you expected to have big change. Nuclear power was going to be too cheap to meter. That was one of the places where you expected to have big change. Nuclear power was going to be too cheap to meter. That was one of the slogans. Nuclear reactors didn't turn out to be particularly cheap. And physics has its beauty. I mean, all right. But I wanted to get a little bit of extra money. So my two choices were working in the food service industry, or I could get a job as a beginning programmer.
36:07Paid better in food service, at least to start. But I said, no, I think I'll do this computer stuff. And one thing led to another. And then somewhere around my junior year, I had been working at IBM. I had been working at what became the Media Lab. I had been working at IBM. I had been working at what became the Media Lab. I had been working at Drapable. I had done a bunch of little computer jobs. And I was getting paid much more than a food service worker. It was good. And my physics advisor and the head of the IBM Cambridge Scientific Center had a lunch where they decided they should do an intervention on me and tell me, Paul, you're not a very good physicist, but you seem to do really well with this computer stuff.
36:55Why don't you change careers and make it easier because we understand some of your goal line mentality stuff, we'll agree to give you the physics degree. It's only a learner's permit anyway. It's just a bachelor's degree. And we'll figure out how to have you double major and you can get a computer science degree. And why don't you just go off and kind of do what you're good at? So that's how I got started. And that's how it all went. It turned out that a bunch of the stuff that we did at the architecture department at MIT was cutting edge computer science at the time. What we did is because people would only give us mini computers because we weren't very important and so forth and so on. Well, we figured out how to network them together and do stuff where we would share.
37:55And at Carnegie Mellon, they had an ARFA-funded project to do pretty much that, figure out how to put together a bunch of mini computers and do distributed work. It sort of sounds a little bit like the cloud, right? So it was cutting edge research, but we just did it because, well, we were doing what we could. When you're working on DNS and you're seeing the Internet growing, did you ever think it would grow as big as it is today or i'm kind of curious to view it from the lens of like right now if you look at the headlines it's ai is kind of exploding and it's you know the this future thing and at the time if you were to look at the headlines when the internet was growing was it a similar type of uh environment i guess that when the internet was growing, was it a similar type of environment, I guess,
38:46that where the internet was this, you know, huge thing? Well, you know, I mean, I kind of grew up in the core of the internet so that I kind of understood it as it was growing. You know, the AI thing, I don't have nearly the same, you know same feeling of intuition on it. So it doesn't feel the same to me at all. Oddly enough, this is like the second or third coming of AI in the sense that I remember in 1985, they had this big AI conference in Southern California over Marina del Rey. And AI was all hot and it was going to take off. And then it disappeared. And the research agencies, ARPA in particular, had had a couple of different things, projects where they had said, if only we could make like more powerful computer or groups of computers, then we can actually kind of do some
39:53of this AI stuff because they, you know, and AI has kind of this history, right? Remember when, you know, do you think you can teach a computer to play chess? Maybe you're too young for that, but you know, once upon a time, having a computer play chess was kind of like AI, right? And in reality, it was if you have a big enough hammer, you can make a chess-playing machine. And a bunch of what happened, particularly with early stuff about being able to understand speech, was people figured out how to put together a big enough database and have enough processing power. A bunch of it was done by brute force. A lot of it is these large language models. There's a bunch of brute force behind the screen.
40:44People talk about, well, gee, we'll figure out how to do it clever. But, you know, there's an awful lot of what AI is doing is trial and error. And it just does trial and error on a huge scale. It can do more errors and more trials than you can imagine. But it gets results. It's a different kind of thing because you do need to have a pretty big machine to do anything interesting. Whereas like I said, we did interesting things for the time back at the architecture machine group with many computers. It was kind of funny because I also had the day job. Well, I didn't have a day job, but I had a part-time job at IBM where they had the biggest machine that IBM made basically there. And I could use it as much as I wanted.
41:39It's very strange because everybody else was like, well, we've got to give you a small amount of time and if you use that up we're not sure we can give you more ibm would give me as much as i wanted um you know and in particular they were having me do things that used an awful lot of machine time so in some sense i kind of time traveled uh because i never had a scarcity of machine time. I always had somebody that wanted to give me as much as I could eat. Nowadays, everybody has it, but it was sort of a little bit different for my career. I think one of the things, you know, the mistakes that I made were all characterized by not doing sufficient understanding about things at the edge. When I talk to college students and give them advice, I say, very often, you can find opportunity
42:37where two fields come together. For example, once upon a time, biology had nothing to do with computers. Now it's all biology and computers, right? You know, I had once upon a time I got a consulting job because I could both speak physics to the physics majors and I could program computers. So DEC was trying to build, they wouldn't tell me that they were DEC for a long time, although it wasn't hard to figure out. But they tested me. They said, well, we hear that you can both program and talk to device physicists. Is that true? I said, yes, I speak both languages. And they gave me a little test. But oftentimes, there's opportunity where two things come together, two fields come together. And so one of the things that says is that you should always be looking for something that's
43:40a little bit beyond the edge of whatever field you're currently in because maybe you can find something else that touches it sort of like doing reconnaissance so you know when I had my index proposal and ARPA and NSF said this isn't research 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 um i mean that happened many times i think i had at least half a dozen different times where i could have started a company if only i knew that well all you have to do to start a company is you know you don't have to understand how to keep books there are people for that and blah, blah, blah. All you need to do is to figure out how to go to Sand Hill Road or the equivalent and ask for money.
44:33I've done that several times. And, you know, it's its own strange view. Once upon a time, you've heard of SoftBank? Yeah. Once upon a time, I had the privilege of introducing SoftBank to its biggest failure. It was a company called Urban Media. And I went to them with a pitch about, hi, we want to go deploy the system in three cities and scale it up if it works. And they said, no, think big or go home. You'll have to do it in all, and this is the way they put it, all of the NFL cities and L.A. So, you know, rather than starting off with a budget of $5 million, they insisted we started off with a budget of $5 million, they insisted we started off with a budget of $50. We eventually burned through $100 million, which was big money at the time, probably
45:34more than that actually. It's funny the way those guys think and the way they work. So, you know, if I could understand Sand Hill Road, I probably would have started many businesses. I don't know why I didn't. But, you know, you find, you know, students who say, well, I don't want to deal with business. 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. Yeah, I know lots of people in startups hate salespeople. They hate marketing people. Yeah, but you need them. So understanding how things work and kind of doing your reconnaissance and particularly looking for something that combines something that you know with something
46:33else where there's leverage there's a lot of ways that i think you can find opportunity when you look back on your whole career and all the experience that you have, if you could go back and give yourself some advice, knowing what you know today, what would you say? I should have paid more attention in French class back in high school because French class in high school was the one thing I loathed. My teachers were insane. They were all of these World War I vets who were, we would say today, PTSD. In those days, we said shell shock. But they were just like crazy. I had one French teacher who was also my homeroom teacher, and he ate Jell-O and potato chips with a fork and knife. Okay. So I just hated it.
47:23I just didn't do French. I just, and then I ended up living in France for eight years. Okay. I probably should have paid more attention way back when. How do you tell if knowledge is useful? Well, all knowledge I think is useful. It's just a question about whether or not you're going to get a chance to apply it. And you don't really know. So why not be a sponge? And I think get a little bit out of your comfort zone. You know, and then there's the whole business about vesting and qualified small business shares and the way that all works. And Silicon Valley pretty much screws the peons and rewards the VCs. And the only difference is kind of a lack of knowledge. I had one company that I was in, and so we're getting bought.
48:21And so OK. And I said, OK, great. So, you know, one of the things I want to do is to make sure that the employees understand about, you know, 1202 qualified small business and the way they can handle the taxes here to make their life good. The people buying, I said, no, they're absolutely forbidden from doing that. Why? They just don't want people rocking the boat, I guess. The other thing is that sometimes, I mean, it was kind of funny because I was just a director on the company. But I had bought into Series A. And I had a bunch of NSOs, some of which I had exercised, so I had shares, and some of which I just had unexercised options. And then there were some things where when they buy you, you lose whatever is invested.
49:21And the tax rates on those were just incredibly different. Well, it turns out that if you had qualified small business stock, basically what you can do is an 83B says that rather than having options that you exercise when they're vested, they give you the options, and you can exercise them immediately, okay? But they can buy the stock back if you leave, if they want to, all right? But the point is, is that you buy it at whatever the price is then. So if the price of a common is, say, a penny a share then, all right, you buy it, and all of it is established with a base of a penny a share. Whereas if you have the option, the company does well, the stock price goes up to $0.10, and you have to exercise it.
50:10You have to pay $0.09 of capital gains there and then. All right. The detail in all of this was that I was paying long-term capital gains on my Series A investment, I was paying zero federal taxes on the common that I got and had invested in 83B. And then the exercisable part of it got taxed at 65%, some absurd rate. I mean, California taxes at all, they don't care. At any rate, the VCs, they know all this stuff. But I would wager that probably, oh, I don't know, 50% of people are paying more taxes than they have to because they don't know about this and they can't get the information. Because to qualify, you have to show that the company was below a certain financial level, and it wasn't of a prescribed type.
51:19Like you can't do this with a real estate company, investment company. And it has to be some percentage US citizens. And it varies a little bit over time. But basically, that's it. And you get a reduced tax rate. My most recent role, I said, OK, I want you to give me the information. I want a list of employees and their citizenship. OK. And I want to know how much capitalization we have. And I just want to get these in a formal way so that when the time comes, I'll know how to handle the taxes. At any rate, to cut back to the story of the company being sold, we eventually agreed not to give our employees tax advice. Okay. We did give them the list of founding employees and what their citizenship was.
52:14And we did, you know, give them, you know, this other thing. And we said that this, you know, you probably want to go read 1202, by the way. And I'm not sure how many of them did. Because, you know, I had a number of different chains on me. I was barely able to squeak this out through the door. But, you know, Silicon Valley, there's a hierarchy there. And it isn't like everybody gets the entrepreneurial spirit and everybody gets the same privileges. Awesome. Well, thank you so much for your time. I really appreciate it, Paul. If you liked it and you want to see the show grow, please support with a comment or a like. Also, if you have any recommendations for people you want me to bring on, please drop a comment. Guests like Barbara
53:11Liskov, Mike Stonebreaker, Mark Brooker, these were all people that I brought on because someone left a comment. On another note, aside from the podcast, I'm working on building the ergonomic keyboard that I wish existed. Here's a glance at the prototype. It's a split keyboard. So there's two sides. This is in the case. But yeah, we launched on Kickstarter and we hit our goal within eight hours of launching. I really appreciate it if you were one of the people who grabbed one of the early units. We're now working on the long journey of building the tooling now. And so if you still want to pick one up, I've left the late pledges open on Kickstarter. So you can grab one there. I'll put a link in the description.
53:49Thank you again for watching the podcast and I'll see you in the next episode.