@ryanlpeterman: This interview is with Paul Mockapetris, the creator of the internet's Domain Name System (DNS). I talked to him about …

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.

In this episode:

• Computing and the internet before DNS existed • Why URLs use reversed names • How DNS works • Migrating the internet to DNS • Advice for his younger self

Where to watch:

• YouTube - https://youtube.com/watch?v=LT4iVeUoL18… • Spotify - https://open.spotify.com/episode/61TliCCkZDV2ZkN6er8yhW… • Apple Podcasts - https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835… • Transcript - https://developing.dev/p/e071-paul-mockapetris…

Thank you to the sponsor of this episode for supporting my work:

• WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://workos.com

Chapters:

00:00 Intro 00:40 What computing was like before DNS 09:02 Why URLs are inverted 16:33 How DNS works 20:27 How he migrated the internet to DNS 25:17 Why do companies host DNS servers 33:17 What is an RFC 35:07 How he got into computing 46:39 Advice for his younger self 52:56 Outro

TL;DR：DNS 之父 Paul Mockapetris 讲述 DNS 诞生前的主机表时代、他在设计中修正的前人错误、URL 顺序与 www 前缀的由来，以及 DNS 如何以树状结构自根向下解析。

DNS 之前的计算环境

一切要从时间点说起：Mockapetris 大约从 1982 年开始思考 DNS。ARPANET 创建于 60 年代末，计算机开始联网，网络上不再只有一台机器。如果实验室里只有一台计算机，给它起名字并无必要——“你想和哪台计算机通信“从来不是问题。但当机器被联在一起时，问题就出现了：你如何决定要从自己所在的那台机器和哪台通信？那时的计算机至少有冰箱那么大，更常见的是占据整个房间，装满风扇、假地板，是“巨大的、令人崇拜的庞然大物”。

随着越来越多的机器接入 ARPANET，人们意识到必须记录它们，于是给它们起名字。等到 Mockapetris 进入这个领域时，已经有一套成熟做法：维护一个由 SRI NIC 组织维护的计算机文件，列出机器名称和它的互联网地址。

这个文件在他刚开始接触计算机时大概只有 50 行，到他着手做 DNS 时大概有几百行。想扩展它，你需要先给 SRI 打电话说“嘿，我要往那个文件里加一行“——而且最好在太平洋时间早上 9 点到下午 5 点之间打，因为那是他们唯一接电话的时间。SRI 把这一行加进去之后，这份文件就像是电话簿的主副本：网络上其他人会说“给我最新的通讯录副本“，你被别人知道的方式，完全取决于是否有人从 SRI 取走了新版文件。

为什么 Mockapetris 拿到了这个项目

他此前在做性能测量方面的研究，但坦言很讨厌那些工作，因为“有很多大名鼎鼎的人也在做同样的事情，我不可能在那上面出头“。DNS 在当时是个不错的、可以交给他的小课题。

人们后来会问：“Paul，你是怎么拿到设计 DNS 这么棒的大项目的？“他的回答是：没人觉得它有多重要。“那只是个小问题，去忙别的吧。“也正因为没怎么监督他，他们才没有把他引向一些更……不那么重要的方向。

他此前的相关积累包括：在 UC Irvine 做过命名工作；在 MIT 本科期间与 Architecture Machine 小组（后来发展成 Media Lab）一起研究多机系统。那个小组当时“很穷、默默无闻，不像今天这么耀眼“。他一直处理多机和分布式系统方面的工作。“我之前在 UC Irvine 的时候设计新的命名系统做得很糟糕，所以有一堆错误我不会再犯了。“还有另一堆错误，是他觉得别人在 Xerox PARC 等工作中犯过的。

他估计，至少 50% 的整体设计想法不是来自互联网社区或当时所在的 USC ISI，而是来自他自己已经做错了好几次的教训：“好吧，这次我要把它做对。“并且这次的场景受众大得多，他预计系统需要扩展到一千万个左右的不同标识。

DNS 的两个“魔法“

人们普遍认识到分布式管理的好处，它也确实做到了：你只需要打一次电话，之后就可以自己管理自己所有的计算机。

但另一点常被忽视——DNS 一直有一个理念：它处理的不只是机器名称。人们说第一个应用是把主机名翻译成 IP 地址（比如 192.168.1.0 之类的），但实际上 DNS 做的第一件事是：找出该问哪个名称服务器才能找到这些信息。DNS 提出的第一个问题不是“给我找个地址“，而是“给我找到我该去哪里查询这个名称“。所以 DNS 用自己的系统来跟踪所有这些数据在哪里。

他把其中的魔法分成两部分：

1. 你可以划分命名空间，并让个人拥有无限期的控制权。今天有数百万个独立的组织拥有他们自己的那块命名空间。
2. 它看起来是一个整体。你不会说“天哪，这太难了，这个名称以 .fr 结尾，它在法国，这肯定很麻烦“，你只会说“哦，它以 .fr 结尾。好的“。

在旧设计中修正的错误

以 Architecture Machine 小组时期为例，他设计过一个文件系统，人们可以有文件名，但从不同的计算机访问它。他当时的做法是“我们让你有一个名字，然后你可以把它组织到目录里“——也就是一个两级名称，有一个最高有效位部分和最低有效位部分。Xerox PARC 在他设计 DNS 时有自己的系统，而且是固定三级的。

他的评价是：“这太蠢了。好的，我要设计成你可以根据需要嵌套任意多级。“因为人们希望有自由来组织他们的信息。大多数人可能用三级或四级，但有很多隐藏的应用会深入很多很多级。“这完全说不通。如果你要费劲让人们嵌套名称，你就应该说：好吧，任意合理的嵌套层级都可以工作。”

URL 为什么是“从最具体到最不具体“

被问到为什么 URL 是倒过来的——maps.google.com 中 com 最大、google 更具体、maps 最具体，之后的路径又像文件目录一样越来越具体——他的回答是：

“你说是倒过来的，我觉得这是显而易见的选择。想想看。“当你输入 URL 时，如果输入 “maps”，系统可能猜出 google.com；但如果输入 “com”，它会指向 google.maps 吗？不会。关键在于你要把具体的部分输入进去，这样如果机器要补全，它才有机会。 显然不能从 com 开始——你说“好吧，那把范围缩小到 2.6 亿个不同的名称“。而如果你碰巧有一台叫 Alice 的机器，系统可以看看本地有什么。这就是顺序如此的原因。

他的态度很明确：“我不会道歉。而且有很多人认为我错了。”

为什么到处都是 www

当时有电子邮件、文件传输协议（FTP），也有万维网。约定俗成的做法是：如果一个组织有 stanford.edu，想访问它的 Web 服务器就在前面加个 www；访问 whitehouse.gov 的 Web 服务器就是 www.whitehouse.gov。

结果是，现在几乎所有人都只是在和 Web 服务器通信。关于独立机器的想法——比如你有 ftp.stanford.edu 之类——“所有那些东西基本上都消亡了”。

他的比喻是：“我为 DNS 做的是，我建了这栋楼的地下一层、地下二层和上面两层。然后人们过来添加了一百种不同的东西，不同的楼层。“这有点像巴塞罗那的高迪大教堂，“有一堆奇怪的形状”。情况甚至更糟，因为在这个基本系统之上已经提出了一百多种不同的扩展，而其中大约一半“在质量上低于平均水平“。

失败的扩展与域名的商业化

一个典型例子是用 DNS 来路由电话。这些人聚在一起做了很多事情，但结果是他们没有注意到人们想要的电话系统功能——比如 800 号码在不同地方是不一样的这个事实。这种机制没有被“互联网天才们“加入进来，因此他们设计的系统在功能上不如已有的系统，存在阻力。

至于“所有这些域名都在被高价出售，我想要的名字我得不到“的抱怨，他指出：这几乎发生在每一个曾经创建的编号系统上。他举了条形码的例子：条形码最初是美国的东西，基本上是一个 10 位数字的代码。有一个组织，如果你来说“我需要一个 5000 个代码的区块“，他们会分配给你然后卖给你。欧洲人说“我们也想加入“，对方很高兴——“因为你们会买很多，我们会从你们身上赚很多钱”。欧洲人说：“不不，我们不想，我们不应该为此付费。“于是他们做了一个 11 位数字的代码，把美国代码的 10 位数字嵌进去（可能是用以零开头的那个），然后宣布剩下的命名空间免费提供。后来航空公司来说“这太棒了，给我们一些数字，这样我们就能追踪乘客的行李”，他们问：“你们准备好了要付钱，对吧？因为我们要收费。”

一旦人们开始拥有这些名称和编号空间，就必须管理它，这需要一些钱，但从中获利的想法总是被放在首位。

规范发布与向 DNS 的过渡

他创建的原始规范于 1983 年首次发布。到 1986 年，系统基本运行起来了。1986 年是第一年，有人实际配置了一个只使用 DNS 的计算机系统，不再有那个旧的主机表——没有它，不再需要了。

过渡过程是完整的：他会每天从 SRI 获取一份主机表的副本，然后立即把它放入 DNS。所以 DNS 始终拥有主机表所有的信息，以及加入并注册了自己域名、开始添加内容的先驱们的所有信息。DNS 随时间推移拥有了主机表的全部内容，还拥有了主机表无法到达的其他地方。

人们对这一点非常怀疑，理由是：“要么是我获取这份表的副本，想知道信息时就查它；要么是我通过互联网发送查询，看看正确的答案是否回来。哪个听起来更可靠？“但只要能以足够可靠的方式运行并提供足够的性能，这几乎是不可避免的。

DNS 在技术上如何工作

把命名空间想象成一棵大树：第一级是所谓的顶级域名，比如 .com 和 .us，然后树状结构在它们下面生长。名称之所以以某种方式结构化，正是为了支持自动补全；但当你试图定位一个名称的服务器时，你是朝相反方向走的。

系统有一个“根“，它实际上是顶层节点，是真正的顶级域名，而且只有一个。所以你总是可以问根。比如你问根：“stanford.edu 在哪里？“根回答：“抱歉 Paul，我不知道，但我知道 edu 在哪里，我知道 edu 的服务器在哪里，所以我会指向它，去问它吧。“你去问 edu 的服务器时，它说：“好的，我知道 stanford.edu。”

所以，为了找到正确的名称服务器而进行的搜索方向与自动补全是相反的。如果你把所有东西想象成树的结构——互联网树和计算机科学中的树总是根在顶部、叶子在底部，“我们就是控制不住自己”。它的规则很简单：如果你能到达顶部，你总是可以往下走一级。

Source: https://www.youtube.com/watch?v=LT4iVeUoL18