记录名称和信息的途径：域名系统

任何人都能够复制这份文档，全部或部分，假若满足：

（1）完整文档的任何拷贝或再版都必须说明来源是Rutgers University，还要包含这个声明；
（2）对这份材料的任何别的用途都必须提及这份指南和Rutgers University，以及这份材料的版权属于Charles Hedrick，必须经过许可才能使用这一事实。
     正象我们先前所提到的,网络软件通常需要一个32-bit的网络地址(Internet address)以建立联接或发送数据包。然而用户更愿意使用计算机的名字而不是数字。因而就会有一个数据库让软件查找计算机名以及与之对应的数字地址。当网络比较小时，这是很简单的：每个系统都会有一个包含所有其它系统的列表文件，既给出它们的名字也给出于之对应的网址。但是现如今（网络中）计算机已经过多从而使这种方法变的不实际了。因而域名服务器代替了这些文件，记录主机域名与相对应的网络地址的途径。（事实上，这些服务器的用途比以上的更全面，这只是存储在域名系统中的信息的其中一种。）请注意有一批连锁的服务器在运行，而不只是一个单独的中央服务器。现在在互联网上有许多不同的机构，如果每当他们安装或移动计算机时都要让他们去告知一个中央的权威这显然是不太实际的。因此，命名权往往委任给一些个人机构。域名服务器形成一个树来与组织结构相对应，这些名字本身带有一个相似的结构。
    以BORAX.LCS.MIT.EDU为例，这是MIT计算机科学实验室（LCS）的一台机器。为了找到它的网络地址，你可能需要潜在地查询4个不同的服务器。首先，你要询问一个中央服务器（称为“根”root）EDU服务器在哪里。EDU是个用来记录（到达）教育机构的途径的服务器。根服务器会给你一些EDU服务器的名称和网络地址（在每一级中都会有好几个服务器以预防其中的一台DOWN掉而不能正常工作）。随后你要询问 EDU与MIT相关的服务器在哪儿。同样的，它会提供给你一些与MIT相关的服务器的名称和网址。通常，并非所有这些服务器都在MIT以预防在MIT大范围电力故障的可能性。随后你会询问MIT与LCS相关的服务器在哪儿，最后你还要询问LCS的服务器之一来找到BORAX。最终的结果就是BORAX.LCS.MIT.EDU的网址。这里的每一级都被称做一个“域”（domain）。而BORAX.LCS.MIT.EDU 这个完整的名字就被成为域名（对更高一级的域也是这样，比如BORAX.LCS.MIT.EDU,MIT.EDU和EDU）。
    幸运的是，在大多数时间里你不是真的必须遵从以上过程。首先是在于根服务器往往碰巧也是顶级域（如EDU）服务器。因此对根服务器的单一查询就可以使你访问到MIT了；其次，通常软件能记住以前见过的回答。所以一旦我们去查找一个在LCS.MIT.EDU中的名字，我们的软件能够记得去哪儿找LCS.MIT.EDU、MIT.EDU和EDU 的服务器。它同样能够记住BORAX.LCS.MIT.EDU的翻译。每一个这样的信息段都会有一个相关的“生存时间”，一般有好几天。过了这些天这些信息段会消失，就得必须再次查找。这也就允许了机构来改变信息。
    域名系统并不局限于查找网络地址，每个域名都是数据库中的一个节点，这个节点能够持有记录来说明许多不同的属性。例如网络地址，计算机类型，以及一系列由计算机提供的服务。一个程序可以请求得到一段特定的信息，或者关于一个特定名字的所有信息。有可能数据库中的一个节点被标识为一个别名，作为通向另一个节点的通道。也有可能使用域名系统来存储有关用户，邮件列表，及其他对象的信息。
    互联网上有一个标准来对这个数据库进行操作，还有相应的协议对之进行规范。每个网络应用都要适合这个规范，因为这是产生主机名的正式的官方的方法。通常应用会和自己主机上的服务器对话。这就削减了每个应用程序的代码数量。
    域名系统对电子邮件尤其重要。对一个特定的名字计算机会有相应的变量域对之进行操作，来确定谁会收到邮件，或者来定义一个邮件列表。