Web Masters Episode #38: Paul Mockapetris


DNS Icon – Free Download, PNG and Vector

Paul Mockapetris:

I discovered that MIT ran these summer classes for high school students and this computer programming one seemed interesting. We used to go over to the computer at the MIT Aero and Astro department. I was there one day doing my thing and the administrator who ran the lab said, “Oh, I got to go pick up my kids from school, will you lock up?” And I said, “I’ll be happy to. I don’t have a key, but I assume I could just press the lock and walk out, right?” She says, “Oh, you don’t have a key? Well, you’re a student, right?” I said, “Yeah.” “Oh okay, here, I’ll give you a key.”

Probably she meant you’re an MIT student, but she didn’t ask the question that way, and so all of a sudden I had a key. I mean the computer center there, was a room that was maybe 20 by 30 feet and had an IBM 1620, which was, by today’s standards of course, it was pretty huge. But it wasn’t really a room-sized computer, it was perhaps one of the first small, mini computer kind of devices. So it was maybe the size of a refrigerator turned sideways and it also had a [inaudible 00:01:17] card punch and those devices that were equally as big. That’s how I got started.

Aaron Dinin:

That was Paul Mockapetris, and as you just heard, his decades long passion for computers and computing was enabled by a poorly worded question from an MIT computer lab administrator. Her mistake gave Paul untethered access to computers during a time when most high schoolers, heck, most people, had never even used one. That turned out to be a fateful mistake because Paul would go on to invent something so critical to the internet, I can almost guaranteed you’re using it right now. He’s the person who created the domain name system. DNS is the address book of the internet so that when you do things like type a domain into your browser, you’ll see the right website, and when you send an email to your best friend, it reaches the right person. That seems important, right? Are you ready to hear the story? Let’s get dialed in.

[INTRO]

Aaron Dinin:

Hi there and welcome to Web Masters, the podcast that explores stories of entrepreneurship by talking with some of the internet’s most impactful early innovators. I’m Aaron Dinin, I’m a serial entrepreneur, I teach innovation and entrepreneurship at Duke University and I research internet history. On this episode, we’re diving into a piece of internet history most people take for granted, and few people even think about in their daily lives. It’s the domain name system, DNS, which we can think of as the internet’s routing structure. The way you most commonly interact with it is by typing domain names into your browser, something like google.com or facebook.com, or amazon.com. Now, how does typing in those domain names get you to the actual websites? That’s the story we’re going to explore on this episode, right after I take a minute to thank our sponsor.

Web Masters is being brought to you with the help of Latona’s. Latona’s is a boutique mergers and acquisitions company that helps people buy and sell cashflow positive internet businesses and digital assets. That includes things like e-commerce stores, Amazon FBAs, content websites, SaaS apps, and domain portfolios, which if you happen to have one, means you should really enjoy this episode about DNS. If you’re looking to sell your domain portfolio or whatever digital asset you own, be sure to contact the team at Latona’s. They combine to have decades of experience brokering deals for internet businesses, and they can help you get a great, great price for yours. Alternately, if you’re interested in buying an internet business, be sure to check out the Latona’s website where you’ll find they’re constantly updating listings of businesses ready to be sold. That website is Latonas.com, L-A-T-O-N-A-S.com.

This episode’s guest, Paul Mockapetris, would go on to have a long entrepreneurial career in tech, but the focus of this episode is going to be a little different than what we normally explore on Web Masters, because most of our episodes are centered around a specific business. On this episode, we’re going to get a bit of a history lesson in innovation by hearing the story of why a core piece of internet infrastructure was created, how it works, and why it matters. But even though this episode isn’t about building a specific business per se, we’ll see that the core entrepreneurial process is still the same. By that, I mean there was a problem with the way things were being done, so someone devised a better solution to the problem and got it to market. It just so happens the solution wasn’t a business, and that’s okay. Remember that entrepreneurship is fundamentally about solving problems. Now, sometimes the best way to solve a problem relies on building a business, but that’s not always the case, and that’s good too. Not that Paul isn’t maybe a little bitter about it.

Paul Mockapetris:

Dan Lynch says that I’m the only guy he knows that invented a billion dollar business, but didn’t really make any money off of it. So yeah, I should’ve made more money. I should’ve had more domain names, et cetera, et cetera.

Aaron Dinin:

Dan Lynch, by the way, was one of the people who helped develop the core TCP/IP protocols that power the internet, and his commentary on Paul’s monetary compensation for developing DNS is probably the most extreme version of a common regret I’ve heard from dozens of early web pioneers. They often joke with me that they should’ve bought lots of domain names before anyone knew how valuable they’d become. Well, imagine being the guy who literally invented the domain name system, and not keeping some of those incredibly valuable domain names for yourself, that’s pretty much what happened to Paul.

But of course, at the time, hoarding domains would never have been a consideration because there was no sense they were precious or valuable things. Instead, Paul was solving a problem in the core architecture of the internet. In fact, if he didn’t solve the problem, the internet might not have become what it is today and domain names wouldn’t even be valuable. To understand how we got to that solution and why it was necessary, let’s start by learning a bit more about Paul’s early experiences with computers and how they impacted his thinking.

Paul Mockapetris:

My affair with computing started in high school. I was in Boston, and a professor at MIT, actually he was a grad student, I think at the time, Stu Madnick, offered a class where high school students could program. I went to that in the summer, so that got me interested. When I went to MIT as an undergrad, I was a physics major, and in order to make ends meet, I had to find some job on the side. Although programming paid like 10 cents an hour less than working in the food service industry, I decided I liked programming better. So I was lucky enough to get a fabulous mentor in Nicholas Negroponte.

Aaron Dinin:

Nicholas Negroponte was the founder of MIT’s famous Media Lab. He also founded the One Laptop per Child association and was the first investor in, and longtime columnist for, WIRED magazine.

Paul Mockapetris:

Most people know him as the founder of the Media Lab, but actually it was the architecture machine before it was the Media Lab, so I was his first employee. I also had a part-time job at IBM, working on virtual machines, so this is actually where I got some of the ideas about distributed computing and so forth because the virtual machine business, you always have to coordinate multiple entities. Around graduation time I did some work with Draper Labs, which was a place that did all of the inertial guidance for the DOD and so forth. I was a real rocket scientist for awhile, but there you had to figure out how to build systems in space that had a lot of redundancy in them, so between the distributed systems and the redundancy, that sort of got into my DNA.

Aaron Dinin:

So you were obviously working with computers from a young age. What made you want to turn them into a career?

Paul Mockapetris:

What was the hot field at the time? Well, it was physics, and in my high school, I learned that I didn’t like to do languages. The school I went to was this odd school called Boston Latin, so I went there for six years from the seventh grade through high school and every year I had to take Latin. There was one period of Latin, just continuously, and then French, which I really disliked. But the math, physics and chemistry stuff I really liked. English and the classics, they were okay, I did okay in them, but it wasn’t really my specialty, if you will, so physics was the hot field in a way, at the time.

The funny part of the story was that in my junior year at MIT, my faculty advisor, who happened to be the chairman of the physics department, and the boss of the IBM Cambridge Scientific Center happened to have lunch together. And as the result of that lunch, they decided to do an intervention on me, where they basically said, “Well, look Paul, you’re struggling as a physics student, you had your problems with…” I remember the course, “… quantum electrodynamics.” Ah yes. “Meanwhile at IBM there’s some of the employees over there that resent you because you’re the high school brat that comes in and does twice as much work that they do in half the time. You’re really good at that stuff. Maybe you ought to consider working on the stuff you’re good at.

“And as a sweetener, we’ll agree that you’ll get your physics degree,” because they know that I had this goal orientation where I latched onto that goal. So if they gave me the consolation prize, I occasionally refer to it as my learner’s permit in physics, as long as I agreed not to practice, they would get me transferred over into what was computer science. So they did and they did me a big favor. I’ve never been very good as a mentee, but somehow or another, I think that over the years, I’ve had an astounding set of mentors who probably shake their heads mostly about, “Why didn’t he listen more?” But I listened enough.

Aaron Dinin:

Well, I can’t speak to whether or not Paul was as bad a mentee as he claims. He’s certainly right that he had an impressive collection of mentors over the years. You already heard about a few of them from his time at MIT, then he traveled west for his graduate studies, where he began working with another group of important digital pioneers.

Paul Mockapetris:

I went to grad school at UC Irvine and there I met Dave Farber who was doing his distributed computing project.

Aaron Dinin:

Dave Farber helped design the first electronic switching system for telephones at Bell Laboratories in the 1960s. He went on to create the world’s first operational distributed computer system that Paul is referring to, before helping build CSNET, NSFNET, and the National Research and Education Network, which were all what you might call early competitors to the internet.

Paul Mockapetris:

This was 1970-ish and they were doing something that looks an awful lot like cloud computing today, except it was kind of with stone age materials. But one of the things I did there was working on hardware that would send messages by name, so some of my ideas about naming came from there. Some came from building an operating system at MIT, where I decided that a fixed level hierarchy was never the way to build names. While I was at UC Irvine, I met Steve Crocker and Jon Postel who were up at University of Southern California.

Aaron Dinin:

Steve Crocker was part of the team that developed the protocols for the ARPANET, which became the internet. He also was the inventor of the Request for Comments series, otherwise known as RFC, which is basically the way the governing structures of the internet determine how to evolve the system. And Jon Postel, well, he was often referred to by early internet pioneers, perhaps somewhat derogatively, as the “god of the internet”, and that’s because he had so much influence over what standards would get adopted. So again, we’ve got Paul working directly under some of the most important people in the history of the internet.

Paul Mockapetris:

They just had a boatload of money from ARPA to work on internet stuff, and so they said, “Hi, would you like to have an office and unlimited computing power, and so forth and so on?” I said, “Sure,” and we skated over the fact that I was supposed to be a USC rather than a UC Irvine student. I was a research assistant there. Dave Farber, who also has the right attitude towards rules, also arranged for me to take a class at Caltech from Carver Mead, and we were building integrated circuits. You might say this sounds like an awful long grad school. Yeah, I was there for 10 years.

Aaron Dinin:

Okay, so you clearly had lots of contact with the early internet pioneers. How did that get you to developing DNS?

Paul Mockapetris:

When I graduated, I was working on measuring TCP performance. Okay, but all the famous people in the world were measuring TCP performance, it was kind of like the issue to work on. I didn’t like it. Then one day Jon Postel came along and said, “We need something to replace this naming system that we have where SRI keeps a table of all the hosts of the internet, and there’s like five proposals about what to do. Why don’t you take a look at figuring out a compromise?”

I looked at all five and decided that nobody would notice if I just ignored them all, and pretty much based on the intellectual DNA that I got from MIT and from IBM, and from Draper Labs about building reliable, distributed systems, I designed the DNS. Which was sort of, I think the first effort to build a system for the internet, where the reliability came from redundancy and always having fallbacks and alternatives, rather than TCP style where you just transmit until you get an acknowledgement, and you just wait forever if necessary.

Aaron Dinin:

Wow, so you just went around everyone else? That’s kind of intense. I want to understand more about your system and I guess why it was better, but before talking about that, can you explain how network traffic was getting routed prior to DNS? What was the problem your system was solving?

Paul Mockapetris:

Sure. Well, what was there before was a system called [host dot text 00:15:22], and basically this was people that would answer the phone at SRI, and if you wanted to create a new machine on the internet or install a new gateway, you would work with them and pick a name, and they would put it in this file. Then the other thing is people around the network would come to SRI and copy that file via FTP, or the FTP of the time. Stanford Research Institute. Once upon a time, it was affiliated with Stanford, but now it’s independent. ARPA had tasked them with being the network information center, which meant that they were keeping track of the configuration of the network for the Department of Defense. That meant that they would publish a catalog of who the researchers were, they would publish a catalog of the machines on the network, but they would also create this file.

And people on the net who wanted to find out what the other machines were on the net, would look this up and it would basically give you a name to address mapping. So WIRED magazine famously described the DNS as being the reason that you can change your network name or add a host on Christmas, and what they were referring to was that Stanford worked 9:00 to 5:00. If you wanted to add a machine at 5:10, you were out of luck, okay? Because they weren’t there to answer the phone. Moreover, it was like publishing phone books, except that you would get a new one perhaps every day, rather than every year. So you had to wait for the people that were on the other end of the conversation, if they wanted to access your resources to get a copy, unless you had two compatible phone books, if you will. It was just like phone books.

Aaron Dinin:

Phone book, that’s usually the best way to describe both DNS and the general addresses protocol that came before it. Basically what happens is that every computer on the internet has an address. In fact, you’ve probably heard the term IP address, which is a series of numbers and characters that tell the network where a machine is located. It’s like a street address for your house. These kinds of numbers are easy for computers to parse, but difficult for humans to remember, we are much better at remembering names and words. To help with this back before even DNS existed, computers were given names, usually based on the institutions where they were located, and those names were assigned to numbers.

Then, as Paul describes, there was a central authority that managed the database, showing the relationship between names and their network addresses. A person would refer to a computer by name when communicating electronically, the computer would ping the centrally managed database to find the address associated with that name, and then the computer would contact the other computer using the address rather than the name. When there were only a small number of machines, the manual system for adding and managing all the computers on the early proto internet worked well enough. However, as the network grew, that became untenable.

One reason obviously was that manual human oversight was inefficient, after all humans don’t like working on weekends, whereas computers don’t seem to mind. The other major problem was that the system wasn’t very scalable or stable, which, considering the increasing importance of the network, was going to be a big problem in the future. Not only did Paul recognize this problem and what was the then current solution, he also saw similar issues in other proposals.

Paul Mockapetris:

There were other people who had had other systems, like I said, there was five proposals. One of which was a system that was created at Xerox PARC to automate the distribution of network configuration information. So it wasn’t like nobody had thought about this problem. Meanwhile, there was OSI that was going to take over the world, the gift from the International Standards Organization. They had a system called X.500 that was going to do this. Basically I sat down and said, “Well, I have my ideas about how this should be done, and there should be no single points of failure,” which meant that one of the starting things was that there’s no one machine that has to be up for you to get the information. What you want to do is to always have redundant copies.

Aaron Dinin:

For the sake of clarity, can you do me a favor and just briefly explain what DNS is?

Paul Mockapetris:

The DNS is a system for creating pieces of what we know as the domain name space. In other words, all the names collected together, if you would, if you had a big list. And it’s a way to carve out a chunk that you own and manage, which means that you can put whatever data you want, and anybody around the world can access your data. People have also modified it so that you can keep parts of it private if you want, and not visible to the outside world. But it’s basically the system that creates names for machines, but also for mail servers and all the other things. It’s a distributed database for the configuration information of the internet, the first level of it.

Aaron Dinin:

Okay, so DNS is the organizational system and the underlying technology for connecting domain names, and some other things, to the locations of machines on the internet, right? And the key is it’s distributed around the world so the list doesn’t live in one place. Why does that matter so much?

Paul Mockapetris:

In order to get the performance up, there’s two ways that you redundantly distribute information, one of which is that if you pull information as a result of a query for a specific thing, you can keep it around for awhile. When I explain the DNS to students, I say, “It’s just like the milk in your refrigerator. If you go to your refrigerator, which is like your DNS cache, and you pick up the milk and the date code says it’s not expired, you’re supposed to be able to drink it and have it work. If the date code expired yesterday, you’re on your own. If you want to use it, we don’t think you should and you should probably throw away things that have timed out.” That was the caching idea behind DNS.

There was also, if you want to do a more wholesale copy. So if, for example, the various different schools at Duke wanted to distribute a different internet information for the different departments in a redundant way, they could copy whole sections of the database. In the original deployment of these things, people like MIT and Harvard were keeping a redundant copy of the other guy’s information. So the information was always available from multiple sources, and then you needed a simple algorithm to figure out how to find where those pieces of information were.

The reason the DNS was successful, and the magic was that I could break off duke.edu and give it to you and say, “Manage it,” and you don’t have to talk to SRI, you don’t have to talk to anybody if you want to add a new machine, you just manage it yourself. And if duke.edu decides that it want to break itself up and have the English department manage their stuff separately, that’s great too. The easy explanation of the DNS’s success is that it let you divide up the management of information to the people that were directly affected by that information, but you could always access any information from anywhere. If you changed something and somebody in Indonesia wanted to look up your new information, they could do it, doesn’t matter where. So that was the technology behind the DNS.

Aaron Dinin:

It’s this last part about different administrators being able to manage their own name spaces separately, that makes the DNS system so extensible, scalable, and reliable. The DNS is, at its core, a highly flexible organizational paradigm, which is a big part of what makes the system so brilliant. Basically every different layer of domain administrator can carve up their domain space however they want, which means Paul’s system, unlike what was previously in place, didn’t require a central manager that would be both a bottleneck for growth and a single point of failure.

In other words, Paul’s innovative, highly scalable solution to the computer addressing problem is a huge part of what’s allowed the internet to become so enormous. Of course, I realize this solution might seem obvious now, but remember at the time it wasn’t obvious at all. In fact, everyone else wanted a central domain name administrator, Paul was the visionary who realized that wouldn’t scale. He’s the person who realized the internet would need a different system, so he borrowed a concept he’d seen working elsewhere. For example, phone numbers use a structure similar to DNS, as does something else you use whenever you go shopping.

Paul Mockapetris:

The DNS isn’t the only place where we have experience with naming systems. If you take a look at the barcode that’s on a product in your office, UPC code, universal product code. The bar code started out as a US thing and then people in Europe wanted to use it. So they went to the US authorities and they said, “Okay, give us a block of numbers that we can use,” and the US said, “This is great, they’re a dollar each, how many do you want?” They said, “No, no, no, we don’t want to pay.”

So basically they created the global system and they just said, “Okay, well you in the US,” I forget, they had like an 11 digit number or something, and so the universal product code now is 13 digits where they just encapsulated the US space. There’s this whole business about selling number spaces, whether it’s phone numbers, or UPC codes, or domain names, where there’s a lot of history about how to market and sell and profit from what’s basically just numbers or names.

Aaron Dinin:

So yes, domain names are like UPC codes and phone numbers, except that domain names also have a layer of cultural cache on top of them, which is part of what makes them so valuable. By that, I mean you’d never refer to a loaf of bread by its UPC code, so an individual UPC code isn’t particularly valuable, whereas entire companies get branded according to their domain names. But that’s not the only thing domain names are good for. DNS also helps support lots of other critical internet operations most of us don’t even realize are taking place.

Paul Mockapetris:

To give you an example, if I send email today, there’s a bunch of DNS lookups that happen in order to get it there. But there’s probably… well, not probably. If you send an email message these days, there’s some look-ups in order to route it, but there’s many more that are there to detect whether or not the message is spam. So the majority of DNS traffic today regarding email, has to do with detecting spam, rather than actually delivering the mail.

Aaron Dinin:

That’s the kind of stuff DNS is doing behind the scenes. But from a public perspective, the most recognizable feature of DNS is of course the naming conventions it creates, things like .com or .net or dot whatever. Oddly enough, from a technological perspective, those names don’t really matter, they don’t really mean anything. In fact, according to Paul, the naming conventions we associate with domains are mainly just the by-product of bureaucracy and organizational inviting.

Paul Mockapetris:

One of the interesting food fights was people think that we have the naming space that we have because it’s the only one. Well, no, in the original designs, a lot of people said the top level domains should be the phone companies. So MCI will manage one set of names, and AT&T will manage another set of names. And the international standards people say, “No, no, no, no, the country code has to be the most important.” The technology in the DNS was made so that you can structure it however you want. We’ve gotten where we’ve gotten by administrative food fights, rather than any part of the technology.

Aaron Dinin:

So where did all the conventions for domain names come from? Why do we have the domain names that we have?

Paul Mockapetris:

Well, I tried to stay out of the administrative side of it. The only place where I put my thumb on the scale was I said, “Hey look, I won’t put up with this it’s got to be country code stuff. We’ll give all the country codes their own top level domain, just so that they don’t bother me. We’ll do some of the generic ones just to show that we can,” and so then you got down into the short strokes of, was it going to be biz or calm or whatever? And I have to tell you, I don’t remember exactly who said C-O-M, com, I don’t remember. But it was one of the ones that was picked and it was picked over the opposition of some of the people in the DOD, because at the time the network wasn’t commercial.

You could be on the network if you were a DOD contractor, but you had to be doing network research work for the Department of Defense. I pointed out to them that, “Well gee, the DNS data might escape the ARPANET.” It could be used by people in private settings. In the DOD, they often talk about using COTS technology for military purposes, and how do you adapt it and so forth? Commercial, off the shelf. So this was a case where the DOD technology was just adopted by people who, they weren’t from the DOD, they didn’t care.

Aaron Dinin:

Just to clarify, you created the technology and then you basically just let other people deploy it however they needed to. Is that a pretty fair description of what happened with DNS?

Paul Mockapetris:

The ICANN and those people spent several decades discovering that they could add new top level domains.

Aaron Dinin:

By the way, ICANN, I-C-A-N-N stands for Internet Corporation for Assigned Names and Numbers. It’s the nonprofit organization responsible for, basically managing and overseeing domain names. They actually operate via a contract with IANA, the Internet Assigned Numbers Authority, which allocates IP addresses. So ICANN’s job is basically to keep the domain names synced with IP addresses.

Paul Mockapetris:

For the longest time, they just didn’t want to do it. They would call me up and they would say, “Paul, we need you to tell us why it wouldn’t be safe to add new top level domains.” And I said, “Well, I’m real sorry, I can’t do that because I don’t believe it’s dangerous. I mean, I wouldn’t go and add a thousand to the 13 that we have, but if you want to add a couple of months and see how it goes or whatever, I think it’s perfectly safe.” They said, “Oh no no, it’s terrible, terrible, dangerous, can’t do that.” Meanwhile, in order to preserve my sanity and keep the people who wanted country codes to be the most important thing, off my back, I said, “Okay, we’ll make a rule that every country can have its country code as a top level domain, and it can manage its stuff however they want.”

All right, so you had France could manage its stuff the way it wanted and the US could do that, blah, blah, blah. And as countries came on the internet, all of a sudden people said, “Gee we have a hundred or so country code, new top level domains and nothing broke. And the technology really doesn’t know what’s a country code and what isn’t, these are things that are allocated by the UN, there’s a little office of a German standards industry that keeps track of what’s a proper country code under the advisement of the UN. So if we add a hundred country codes, well, why couldn’t we add a hundred non-TLDs?

The commercial people came in and the commercial people, they weren’t motivated by the same, “Oh no, no, no, we have to be careful about the stability,” and so forth. They said, “We want new top level domains because we think we can make money,” so ICANN opened the flood gates, although there were a lot of people who had spent a lot of time talking about how it was going to be the end of the internet, nothing happened. It might’ve been a little bit like the Y2K problem. There were some things that needed to get fixed, but today God knows how many top level domains we have.

Aaron Dinin:

As of this recording, according to ICANN, there are actually 1,514 TLDs. The core ones you know, like .com and .net, then the country codes, and in the last decade, ICANN allowed applications for generic top level domains, GTLDs. These are the commercial domains that allow for websites ending in things like .tech, or .store, or .travel. The point being, as Paul pointed out all along, the domain name system is highly extensible. It’s really just an organizational paradigm, more than a specific technology. The computers don’t care what the characters in the domain say, those characters are there for us humans, we’re the limiting factor. Of course, that hasn’t stopped people from trying to change or replace DNS with something different or better. Lots of people have argued with Paul over the years that DNS has too many limitations, but as you’d probably expect, he disagrees.

Paul Mockapetris:

One of the things I’ve run into repeatedly with the DNS is where I get an opportunity to tell people, “Look, the DNS works in practice, if not in theory. It’s very persuasive of me to know that it works out there in the real world, and your proof about how it doesn’t work, I’m not really going to pay much attention because I know it does.” It happens over and over. I love theory, but there’s too many people that come up with theories based upon really what was a commercial imperative about not empowering people to break their monopoly.

But from my physics background, there’s, I think it’s Newton’s second law that says that for every action, there’s an equal and opposite reaction. I apply that to the internet because there was a slogan, the internet changes everything, but there’s also, well the real world changes the internet back. So a lot of the architectures that you see that are out there today for the internet, are a mixture of engineering design and people wanting to make money, or preserve commercial interests, or whatever. So it’s yet another hurdle that new designs have to pass, but it’s the real world and it’s a deployed system now.

Aaron Dinin:

It is definitely a deployed system, it’s proven literally trillions upon trillions of times to be an effective solution to a challenging problem. In fact, even though most of us never think about DNS in our daily lives, it is at the core of the way our world operates. Paul’s invention literally impacts just about everything we do. How crazy is that? So the next time you send an email, or visit a website, or even listen to a podcast, maybe take a moment to thank Paul Mockapetris for creating a system that works so darn well. I’d also like to thank him for spending time with me on today’s episode and sharing the story behind the domain name system, and I want to thank you for listening. If you want more, be sure you’re subscribed so you get the next episode as soon as it’s released. Also, if you’ve got a moment, please leave a nice review and maybe even share this episode with someone you think will like it.

If you have any questions, thoughts, or feedback, you can reach us on Twitter. We are @WebMastersPod. I’m on Twitter too @AaronDinan, that’s A-A-R-O-N D-I-N-I-N. You can also follow me on medium.com just by searching my name, you’ll find lots of articles about startups, innovation, and entrepreneurship. A quick thanks to Ryan Higgs, our audio engineer for his help pulling together this episode, and another thanks to our sponsor Latona’s for their support. Remember if you’re interested in buying or selling an internet business, be sure to check out Latonas.com. And of course, one last thanks again to all of you for listening. We’ll be back again soon with another episode of Web Masters in just a few days. Until then, well, it’s time for me to sign off.

Leave a Reply

Your email address will not be published. Required fields are marked *