loading
loading
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. Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts. Timestamps 00:40 - What computing was like before DNS 20:27 - How he migrated the internet to DNS 25:17 - Why do companies host DNS servers 35:07 - How he got into computing 46:39 - Advice for his younger self Transcript 00:40 — What computing was like before DNS Ryan: [00:40] Before we talk about DNS getting created, I’d like to go over what computing was like before DNS? Paul: [00:50] Well, it depends on where, how far before DNS. But just to put a post in the ground, I started thinking about DNS probably in 1982. Now, to back up 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. [01:21] Which computer do you want to talk to is ever an issue. But when you start networking them together, then the question comes up: how do you decide which one you want to talk to from whichever one you happen to be at? Because in those days, the computers we’re talking about were big machines, at least refrigerator size, shall we say, and more often a whole room size, packed with fans and false floors and all like that. [01:51] Big, huge things that we would worship anyway. So people started connecting more and more of them with the ARPANET. And at some point they said, well, we 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 organization called the SRI NIC, and that file would list a machine name and basically its Internet address. [02:24] And so that file, at the time I started playing with computers, was probably 50 lines long. And when I started doing 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 are calling during 9 to 5 Pacific time, because that’s the only time they would answer the phone. [03:01] So they added to that file. Now, 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, 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. [03:34] 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. What could you do next? Was a nice little research problem that they could hand off to me. People now say, well, Paul, how’d you get this wonderful big job designing the DNS? Nobody thought it was that important. [04:04] 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 Group, which went on to become the MIT Media Lab, okay. But they were poor at the time and unknown, not like the flashy thing they are today. [04:42] So they had multiple machines that they needed to connect. So I had always been working with multiple machines and distributed systems. And 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 ones, work that had gone on like Xerox PARC and so forth. [05:09] So till 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. [05:42] Now, the thing that was, I think, really important that people didn’t realize, people realized 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, okay? 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. [06:08] 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. Okay? I mean, people say, well, the first application was this business about translating a host name or computer name to an IP address, you know, 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. [06:44] That was the first question that ever got asked by 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. [07:16] 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 France. This is going to be hard. Nope, just go, it ends in .fr. Ryan: [07:31] Okay, you mentioned in some of your 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? Paul: [07:43] For example, when at the Architecture Machine Group, 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. You have the most significant part and the least significant part, two-level names. [08:11] 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 at however many levels you want, because people want to have freedom to organize their information. And you might say, well, mostly people use three levels or four levels, but there are lots of hidden applications where they go many, many, many levels deep. [08:45] 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. 09:02 — Why URLs are inverted Ryan: [09:02] 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, the biggest one, Google’s the more specific, Maps is the most specific. And then after that there’s the path, which is also like a file directory. So it gets more and more specific as you go. Why is it inverted like that? Paul: [09:32] You say inverted, I say it’s an obvious choice. Think about this, okay? 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 Maps? No. So the point is that what you want to do is to put in the part. So if the machine is going to complete it, it has a chance, right? Obviously, start with .com. You go, okay, well that narrows it down to 260 million different names, right? [10:05] Whereas if what you do is you type, oh, I don’t know, you happen to have a machine called Alice, it may be able to say, oh, okay, I’ll look what’s around locally. And 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. Ryan: [10:22] What about the www? www in the beginning, because that I could go www.maps.google.com, and that www feels like a very generic thing, or it seems to just be prepended to a lot of URLs. What is that, and why is it there? Paul: [10:40] Well, what happened was that there were different things. There was email, there was what was called File Transfer Protocol, and there is 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. Okay, 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 to the web server for Stanford, you put a www in front of Stanford.edu. [11:10] If you want to talk to the web server at whitehouse.gov, well, you go www.whitehouse.gov. Now it turns out that pretty much all people do is talk to web servers, right? I mean, it turns out that that whole idea about separate machines and that you would have FTP, Stanford.edu, or whatever, all that kind of 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. [11:53] And then people came all along and added 100 different things, different floors. It’s a little bit like Gaudí’s cathedral in Barcelona. It kind of like there’s a bunch of strange shapes, but seeing as everybody did it, it’s kind of worse than that because there’s been over 100 different additions 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. [12:22] So it’s a bunch of ideas that failed. There’s a bunch of ideas that didn’t turn out the way people thought. 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 the same everywhere. [13:00] 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. [13:32] 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. Barcode started out as a U.S. thing, where it was basically a 10-digit code, all right? And there’s an organization that if you came along and you said, okay, I need a block of 5,000 codes, they would allocate it to you and they’d sell it to you. [14:06] So the Europeans said, “Oh, well, we want it on this.” And they said, “Well, that’s great, 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 U.S. codes with, I don’t know, probably with the thing that starts with zero. [14:29] And then they said, well, okay, we’ll give away the rest of the namespace, all right. And so then airlines came to them and said, oh, this is great, give us some numbers so that we can keep track of passengers’ bags. And they said, okay, well, you’re ready to pay, right, because we’re going to charge you, so it’s. Once people start to own some of these name and number spaces, they of course have to manage it, and that costs some money. [15:00] But the idea of making a profit out of it is always front and center. I mean, the other thing that happened with DNS is I created the original specs, and 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 DNS and didn’t have any of that old host table thing. It just wasn’t necessary. [15:34] 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. So 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. So 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. [16:07] 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, okay, 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? 16:33 — How DNS works Ryan: [16:33] How does DNS work in terms of the high-level technical pieces? Paul: [16:38] 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. [17:05] Because what you do is you say, okay, we have this thing called the root, which is really the node that’s on top. It’s the real top level debate. 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. [17:31] Go ask that. So then when you go ask that, it says, okay, I could. 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, it all being organized as a tree structure, you know, Internet trees and computer science trees are always kind of like the root is up at the top and then the leaves are down at the. [18:00] You know, we can’t help ourselves. At any rate, it says that if you can get to the top, you can always go down one level. Okay. 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. So if you can get to the top, you can always go to the bottom. And so 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. [18:33] 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 root. Ryan: [18:48] How did you convince yourself that performance wouldn’t be an issue if you had to do all these recursive calls? Paul: [18:54] 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, where is the web server for UCI Edu for UC Irvines? When you get back, the answer for that, it comes with a timestamp on it that says, okay, you can assume this doesn’t change for some number of seconds. Okay? And what people often would do is for things that don’t change very often, what they would do is that say, okay, you can keep that information for a day. [19:31] So there’s this caching infrastructure such that if you get it, you don’t have to look it up again for 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 know, you’re going in your pantry. Canned beans, best of used this century. You know, I mean, basically the information is all timestamped like that so that you can know how long you can keep it. [20:03] 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, right, Then you only pay the cost. One out of many, many, many accesses. 20:27 — How he migrated the internet to DNS Ryan: [20:27] Well, so I guess the big question in my mind is how did you convince people that performance and reliability would be acceptable? Paul: [20:34] Well, you know, basically what happened was every morning I would get a copy of the existing standard and I would pump all those names into the DNS. So they would. 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. [21:04] They didn’t bother to update the hose 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. And 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 hang, hung out. [21:30] And you know, the, the other thing that’s kind of amusing is that in the early days of the Internet, the SRI NIC was three people, okay? 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 paying to register Stanford Edu’s machines one by one? [22:00] And you know, as the NSF net expanded and things weren’t all run by the ARPA or, or the ddn, they said, 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 it for maintaining it for our own people? And so that’s when people started thinking about splitting off. You may have heard of the mill net, any rate, that was sort of a network that was going to be used for real military stuff. [22:34] And why are we going to do that? It’s kind of funny because you know, the sponsorship of the DNS research also came along, like in the late 1980s. They were kind of 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 wizzy and innovative and so forth. So we’re not going to pay you anymore for that. [23:03] And I had sent them a proposal for what I thought was the next level of the DNS, and they said, no, no, it’s not. That’s not like cutting edge research. All this DNS stuff, that’s old. I sent in a proposal to NSF and I said, okay, 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, you know, who has files of what. [23:34] And so I wrote up a proposal, I sent it to nsf and they said, paul, you’re crazy. There’s like thousands of machines. You can’t possibly keep up with all that. Okay, so this is where Paul made one of his fundamental errors. You say, why didn’t you register 10,000 names and go to a beach and wait for them to all be worth a million dollars? Ryan: [23:54] Do you ever think about that? You could have owned those things. Paul: [23:57] Well, you could have mined Bitcoin in your younger days and. Right, that’s fair. You had a 286 laptop, could have mined a few billion dollars worth of Bitcoin without much trouble. Right? 25:17 — Why do companies host DNS servers Ryan: [25:17] You mentioned those, those root servers that we go to Initially, what’s the economic incentive or who’s paying for those servers? [25:24] What’s the economic incentive for those 13 clouds that exist? Paul: [25:28] 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, 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 month. And then one day the Europeans walked in and said, we need a European root server. [25:57] And today I’m not sure why. I mean they certainly, 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, Google 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. [26:42] There’s this big discussion that the Internet old boys have. They go, you know, it’s, God, 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. [27:14] But there’s a lot of people that would, you know, say there’s, there’s got to be a conspiracy theory here. The big companies, you know, they claim that they don’t collect data there. Okay, they claim that they don’t collect data there. And I would never, you know, I would never accuse them of trying to make a profit. I’m so. Well, never mind. You know, 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. [27:53] 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, most people don’t realize that when an ad gets populated on their webpage, 150 or more organizations have been asked, do you want to serve this ad to this person? [28:40] 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. Ryan: [29:02] 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. Paul: [29:17] Well, sure. I mean, I can suggest a couple of things. One of which is that Microsoft, for example, knows 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. All right? 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. [29:49] And so I guess that’s a win win. I don’t think that’s all there is to it. But, you know, 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. Although we had given them control of everything under. fr after that, it was up to them to make whatever process they wanted. [30:22] And so they said, well, we have to have a deposit. You have to fill out this form, make it very complicated. All right? So along comes a 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, okay? And because the Germans gave them a country code of. nu they got to have their own top level domain. So the guy goes to Nuay and says, hey, I’ll make you a deal. [31:00] I’ll run the NUE 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 and 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 kroners and you can have any name that’s not in Use I charge you per name. [31:36] 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 dot EDU translates to new or cool or nude, but maybe people don’t care about that. At any rate, so he starts registering tens of thousands of names and all these people who, okay, they, they want their own domain. [32:07] They, that and they’re, they’re in France and the French government is making it tough. We’re registered under New Way and 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. [32:45] There was kind of some supposed stories about, you know, dot 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 Co can’t get a dot com. Well, you could get a dot co. It’s close. So, you know, this is another one of these, ownership of the namespace and so forth. 33:17 — What is an RFC Ryan: [33:17] When I was reading about, I guess, some of the history of this work, there’s all these RFCs. And my high level understanding is that’s a name for an engineering proposal. But I’m curious to know what’s the, the culture behind an rfc? Paul: [33:34] Well, that’s evolved over time. In the good old days, people would, you know, 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. [34:03] In time though, 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. And if it’s like reasonably cogent, you can probably get an RFC number for it. And you know, but then there’s standards track stuff that are going to be Internet, they’re going to be standards and they’re, you know, politics and paperwork. [34:38] You know, there’s a whole lot of process. You know, the, the, the ITF 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? 35:07 — How he got into computing Ryan: [35:07] 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? Paul: [35:16] MIT was offering some summer classes for high school students, and I just took one and I was kind of fascinated. But I was a physics major. I was, 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. You know, nuclear power was going to be too cheap to meter. [35:45] That was one of the slogans. You know, nuclear reactors didn’t turn out to be particularly cheap. And physics has its beauty, you know, 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. Paid better in food service, at least to start. But I said, no, I think I’ll do this computer stuff. [36:11] And one thing led to another. Um, and then somewhere around my junior year, I had been working at IBM. I’d been working at the, what became the media Lab, I working at Draper. I. I’d done a bunch of little computer jobs and I was getting paid much more than a food service worker. It was good. And my physic
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. Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts. Timestamps 00:40 - What computing was like before DNS 20:27 - How he migrated the internet to DNS 25:17 - Why do companies host DNS servers 35:07 - How he got into computing 46:39 - Advice for his younger self Transcript 00:40 — What computing was like before DNS Ryan: [00:40] Before we talk about DNS getting created, I’d like to go over what computing was like before DNS? Paul: [00:50] Well, it depends on where, how far before DNS. But just to put a post in the ground, I started thinking about DNS probably in 1982. Now, to back up 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. [01:21] Which computer do you want to talk to is ever an issue. But when you start networking them together, then the question comes up: how do you decide which one you want to talk to from whichever one you happen to be at? Because in those days, the computers we’re talking about were big machines, at least refrigerator size, shall we say, and more often a whole room size, packed with fans and false floors and all like that. [01:51] Big, huge things that we would worship anyway. So people started connecting more and more of them with the ARPANET. And at some point they said, well, we 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 organization called the SRI NIC, and that file would list a machine name and basically its Internet address. [02:24] And so that file, at the time I started playing with computers, was probably 50 lines long. And when I started doing 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 are calling during 9 to 5 Pacific time, because that’s the only time they would answer the phone. [03:01] So they added to that file. Now, 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, 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. [03:34] 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. What could you do next? Was a nice little research problem that they could hand off to me. People now say, well, Paul, how’d you get this wonderful big job designing the DNS? Nobody thought it was that important. [04:04] 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 Group, which went on to become the MIT Media Lab, okay. But they were poor at the time and unknown, not like the flashy thing they are today. [04:42] So they had multiple machines that they needed to connect. So I had always been working with multiple machines and distributed systems. And 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 ones, work that had gone on like Xerox PARC and so forth. [05:09] So till 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. [05:42] Now, the thing that was, I think, really important that people didn’t realize, people realized 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, okay? 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. [06:08] 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. Okay? I mean, people say, well, the first application was this business about translating a host name or computer name to an IP address, you know, 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. [06:44] That was the first question that ever got asked by 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. [07:16] 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 France. This is going to be hard. Nope, just go, it ends in .fr. Ryan: [07:31] Okay, you mentioned in some of your 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? Paul: [07:43] For example, when at the Architecture Machine Group, 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. You have the most significant part and the least significant part, two-level names. [08:11] 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 at however many levels you want, because people want to have freedom to organize their information. And you might say, well, mostly people use three levels or four levels, but there are lots of hidden applications where they go many, many, many levels deep. [08:45] 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. 09:02 — Why URLs are inverted Ryan: [09:02] 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, the biggest one, Google’s the more specific, Maps is the most specific. And then after that there’s the path, which is also like a file directory. So it gets more and more specific as you go. Why is it inverted like that? Paul: [09:32] You say inverted, I say it’s an obvious choice. Think about this, okay? 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 Maps? No. So the point is that what you want to do is to put in the part. So if the machine is going to complete it, it has a chance, right? Obviously, start with .com. You go, okay, well that narrows it down to 260 million different names, right? [10:05] Whereas if what you do is you type, oh, I don’t know, you happen to have a machine called Alice, it may be able to say, oh, okay, I’ll look what’s around locally. And 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. Ryan: [10:22] What about the www? www in the beginning, because that I could go www.maps.google.com, and that www feels like a very generic thing, or it seems to just be prepended to a lot of URLs. What is that, and why is it there? Paul: [10:40] Well, what happened was that there were different things. There was email, there was what was called File Transfer Protocol, and there is 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. Okay, 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 to the web server for Stanford, you put a www in front of Stanford.edu. [11:10] If you want to talk to the web server at whitehouse.gov, well, you go www.whitehouse.gov. Now it turns out that pretty much all people do is talk to web servers, right? I mean, it turns out that that whole idea about separate machines and that you would have FTP, Stanford.edu, or whatever, all that kind of 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. [11:53] And then people came all along and added 100 different things, different floors. It’s a little bit like Gaudí’s cathedral in Barcelona. It kind of like there’s a bunch of strange shapes, but seeing as everybody did it, it’s kind of worse than that because there’s been over 100 different additions 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. [12:22] So it’s a bunch of ideas that failed. There’s a bunch of ideas that didn’t turn out the way people thought. 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 the same everywhere. [13:00] 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. [13:32] 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. Barcode started out as a U.S. thing, where it was basically a 10-digit code, all right? And there’s an organization that if you came along and you said, okay, I need a block of 5,000 codes, they would allocate it to you and they’d sell it to you. [14:06] So the Europeans said, “Oh, well, we want it on this.” And they said, “Well, that’s great, because you’re going to have to buy a lot. We’l
document fetched 2026-10-24 11:26 · canonical https://developing.dev/p/e071-paul-mockapetris