详情
本书第5版内容覆盖了BIND 9.3.2（BIND 9系列的最新发布版本），以及BIND 8.4.7。BIND 9.3.2包含了安全方面的进一步改进，并支持Ipv6以及重要的新特性，例如国际化域名、ENUM（电话列表）以及SPF（发送者安全框架）。无论你是DNS系统的日常管理员，或者是想了解Internet工作原理的用户，本书都是必备的参考书。
书名：DNS与BIND（第5版）
ISBN：978-7-115-33599-9
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 [美] Cricket Liu Paul Albitz
译 房向明 孙 云 陈治州
责任编辑 傅道坤
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Copyright © 2006 by O’Reilly Media, Inc.
Simplified Chinese Edition, jointly published by O’Reilly Media, Inc. and Posts & Telecom Press, 2013. Authorized translation of the English edition, 2006 O’Reilly Media, Inc., the owner of all rights to publish and sell the same.
All rights reserved including the rights of reproduction in whole or in part in any form.
本书中文简体字版由O’Reilly Media, Inc.授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式复制或抄袭。
版权所有，侵权必究。
DNS（域名系统）是Internet中的一项核心服务，用于实现IP地址和域名之间的相互映射，能够使人们方便地访问Internet。BIND（Berkeley Internet Name Domain）则是Internet上使用最广泛的源码开放的DNS服务器软件。
本书是DNS与BIND的权威指南，共17章，分别介绍了DNS的发展动机、概念、运行机制；BIND的安装、配置、维护；使用MX记录来发送邮件；子域的划分；对域名服务器的保护；DNS安全扩展和事务签名；常用的DNS调试工具和排错技术；理解调试输出；以及进行DNS编程等知识。本书最后的5个附录还对DNS的消息格式、BIND中的重要功能、在Linux上编译和安装BIND、Internet中的顶级域，以及BIND名称服务器和解析器的配置，进行了讲解。
本书适合各个水平的BIND系统管理员和网络管理员阅读，也适合打算进行BIND编程的程序开发人员，以及想要深入理解DNS工作原理的用户阅读。
O’Reilly Media通过图书、杂志、在线服务、调查研究和会议等方式传播创新知识。自1978年开始，O’Reilly一直都是前沿发展的见证者和推动者。超级极客们正在开创着未来，而我们关注真正重要的技术趋势——通过放大那些“细微的信号”来刺激社会对新科技的应用。作为技术社区中活跃的参与者，O’Reilly的发展充满了对创新的倡导、创造和发扬光大。
O’Reilly为软件开发人员带来革命性的“动物书”；创建第一个商业网站（GNN）；组织了影响深远的开放源代码峰会，以至于开源软件运动以此命名；创立了《Make》杂志，从而成为DIY革命的主要先锋；公司一如既往地通过多种形式缔结信息与人的纽带。O’Reilly的会议和峰会集聚了众多超级极客和高瞻远瞩的商业领袖，共同描绘出开创新产业的革命性思想。作为技术人士获取信息的选择，O’Reilly现在还将先锋专家的知识传递给普通的计算机用户。无论是通过书籍出版、在线服务或者面授课程，每一项O’Reilly的产品都反映了公司不可动摇的理念——信息是激发创新的力量。
“O’Reilly Radar博客有口皆碑。”
——Wired
“O’Reilly凭借一系列（真希望当初我也想到了）非凡想法建立了数百万美元的业务。”
——Business 2.0
“O’Reilly Conference是聚集关键思想领袖的绝对典范。”
——CRN
“一本O’Reilly的书就代表一个有用、有前途、需要学习的主题。”
——Irish Times
“Tim是位特立独行的商人，他不光放眼于最长远、最广阔的视野并且切实地按照Yogi Berra的建议去做了：‘如果你在路上遇到岔路口，走小路（岔路）。’回顾过去Tim似乎每一次都选择了小路，而且有几次都是一闪即逝的机会，尽管大路也不错。”
——Linux Journal
无论在何时使用Internet，人们都会用到域名系统（Domain Name System，DNS），尽管人们可能还是对DNS知之甚少。实际上，每次发送电子邮件或在万维网（World Wide Web）上冲浪，都必须依赖于域名系统。
我们更倾向于记忆计算机的名称，而计算机却更喜欢使用数字来找到彼此。在互联网上，这个数字长达32位（bit），或者说是从0到大约40亿之间的一个数字[1]。对于计算机来说，这些数字很容易记忆，因为它们所拥有的大量内存很适合用来储存数字，但是对于人类来说，记忆这些数字就不那么容易了。从电话簿中随机挑出10个电话号码，然后试着记住它们。不容易吧？现在再在每个电话号码前加上随机的区号。这大概就和记住10个任意的互联网地址差不多难了。
这就是需要域名系统的部分原因。DNS负责将人类方便记忆的主机名称，解析成计算机能够处理的互联网地址。实际上，DNS是Internet上，用来发布和访问关于主机的各种信息（而不仅仅是地址）的标准机制。并且几乎所有需要网络连接的软件都会用到DNS，包括电子邮件、远程终端程序（例如ssh）、文件传输程序（例如ftp）以及网络浏览器（例如Microsoft的Internet Explorer）。
DNS的另外一个重要功能就是：让整个Internet都能够得到主机的信息。将主机的相关信息以文件格式保存在一台独立的计算机上，则只有该计算机的用户才能使用它。而DNS提供了一种方法，能够从网络上的任何地方远程检索到该信息。
不仅如此，DNS还能将对主机信息的管理分布到许多站点和组织。有了DNS，就不必再向中心站点提交自己的数据，也不必再定期检索主数据库的副本。只需要确保自己名称服务器上的区域（zone）数据是最新的即可。名称服务器会使该区域的数据在网络中所有其他名称服务器上都可用。
因为其数据库是分布式的，所以系统还需要能够通过搜索一些可能的位置，来找到所查询的数据。有了域名系统，名称服务器就能通过浏览数据库来找到任何区域中的数据。
当然，DNS也存在一些问题。例如，为了冗余，系统允许使用多个名称服务器来储存关于某个区域的数据，但这会导致区域数据副本之间内容不一致的问题。
不过DNS所面临的最糟糕的问题是：尽管其在Internet上被广泛应用，但是却真的很少有关于如何管理和维护DNS的文档。Internet上的大部分管理员只能参考其厂商所能够提供的文档，再就是从相关主题的Internet邮件列表和Usenet新闻组中搜集一些这方面的信息。
缺乏文档就意味着：对于一个极其重要的internet服务（现在是Internet的重要支柱之一）的理解，要么从一名管理员传授给另一名管理员，就像祖传秘方一样；要么由一个个孤立的程序员和工程师来反复重新学习。新的区域管理员仍然会犯着无数人曾经犯过的错误。
写作本书的目的就在于帮助改善这种状况。不是所有读者都希望或者有足够的时间成为DNS专家。毕竟，大部分人除了管理自己的区域和名称服务器以外，还有大量的工作要做：系统管理、网络工程或是软件开发。只有在非常大的机构中，才有可能提供专人负责DNS。无论是运行一个小型区域还是管理一个巨型跨国公司，无论是照料一个名称服务器还是管理数百个名称服务器，本书都会试着提供足够的信息，让读者能够完成所需的工作。读者目前需要知道多少内容就可以只阅读多少，等以后需要学习更多知识时再回来接着读。
DNS是一个很大的主题——大到需要两位作者才能完成，不过，本书将尽可能地使其易于理解。本书前两章将提供很好的理论概述以及足够的实践资料，其他章节将讲解具体细节。本书会事先提供一份阅读指南，以便读者能够根据自己的工作或兴趣来选择合适的学习路线。
本书在谈到实际的DNS软件时，几乎指的都是BIND（Berkeley Internet Name Domain），这是目前最流行的DNS规范（并且也是作者已知最好的）。作者将尽力把使用BIND来管理和维护区域的经验提炼到这本书中。（顺便提一句，作者所管理的其中一个区域，曾经是Internet上最大的区域之一，当然这已经是很久以前的事了。）只要有可能，作者还将提供在管理中实际使用到的程序，为了提高速度和效率，其中很多程序已经用Perl重写了。
如果刚开始接触DNS和BIND，作者希望这本书能够帮助读者熟悉它们；如果已经对它们有所了解，则本书将能够增强读者对其的理解；即使对它们了如指掌，本书也能够为读者提供宝贵的见解和经验。
本书第5版主要讨论新的和8.4.7版的BIND，以及BIND 8和9的较早版本。虽然在本书写作时，BIND的最新版本是9.3.2和8.4.7，但是许多厂商还没有将它们应用到各自的UNIX版本中，部分原因是由于这两个版本最近才刚刚发布，许多厂商对这种新软件都持有谨慎的态度。本书偶尔也会提到其他版本的BIND，因为许多厂商仍然继续发行包含老版本BIND代码的UNIX产品。无论是只适用于BIND 8.4.7或9.3.2版的功能，还是在不同版本之间功能有所不同，本书都会尽力指出其在每个版本中的作用。
在本书的示例中，频繁使用了nslookup（一个名称服务器的实用工具），并且所使用的是封装在BIND 版代码中的版本。老版本的nslookup虽然也提供了9.3.2版中nslookup的大部分功能，但还不是全部。在本书示例中，会尽量使用对大部分版本的nslookup都通用的命令；如果无法做到，本书将会加以说明。
除了更新本书内容以涵盖最新版本的BIND外，第5版中还增加了相当多的新内容：
涵盖了发件人策略框架（Sender Policy Framework，简称SPF），请参阅第5章；
更广泛地覆盖了动态更新（dynamic update）以及NOTIFY，包括已签名的动态更新和BIND 9中新的更新策略（update-policy）机制，请参阅第10章；
增量区域传输（Incremental zone transfer），同样请参阅第10章；
支持条件转发的转发区域（forward zones），请参阅第10章；
使用AAAA记录和ip6.arpa进行IPv6的正向及逆向解析，请参阅第10章的最后部分；
事务签名（transaction signature，TSIG），一种事务认证的新机制，请参阅第11章；
扩展了保护名称服务器的部分，请参阅第11章；
扩展了应对Internet防火墙的部分，请参阅第11章；
涵盖了修订后的DNS安全性扩展（DNS Security Extensions，简称DNSSEC），一种对区域数据进行数字签名的机制，同样请参阅第11章；
增加了全新的一章（第16章），讲述了如何为一个组织设计完整的DNS架构；
ENUM，用于将E.164电话号码映射为URI，请参阅第17章；
国际化域名（Internationalized Domain Names，IDN），一个采用Unicode字符来编码域名标签的标准，请参阅第17章；
BIND适应Active Directory的修订部分，请参阅第17章。
本书对内容的组织，或多或少是按照区域及其管理员的发展过程而来的。第1章和第2章讨论了域名系统的理论知识。第3章到第6章帮助读者决定是否建立自己的区域，还讲述了如果要建立自己的区域，那么应该如何去做。本书中间的几章（第7章到第11章），讲述了如何维护自己的区域，如何配置主机来使用自己的名称服务器，如何规划区域的发展，如何创建子域以及如何保护名称服务器。第12章到第16章讨论了排错工具、常见问题以及使用解析器库例程（library routines）来编程时一些不为人知的技术。第16章将这一切整合到一个端到端的架构中。
下面是关于每一章内容的详细介绍。
第1章，背景
从历史的角度，讨论了DNS发展的动机，然后是对DNS理论的概述。
第2章，DNS的运行机制
涉及了DNS理论的更多细节，包括DNS命名空间的组织结构、域、区域以及名称服务器。还介绍了例如名称解析及缓存等重要概念。
第3章，从哪里开始呢
讲解了如果还没有BIND软件，那么应该如何取得它，以及得到后该怎么做；如何正确选取域名，以及如何联系可以对自己区域进行授权的组织。
第4章，建立BIND
讲述了如何建立前两个BIND名称服务器的细节，包括创建名称服务器数据库，启动名称服务器以及检查它们是否正常工作。
第5章，DNS和电子邮件
讨论了DNS的MX记录，它允许管理员指定替代主机来处理发往特定目的地的邮件。本章讲解了多种网络和主机的邮件路由策略，包括使用Internet防火墙的网络和无法直接与Internet连接的主机。本章还包括了发件人策略框架，它使用DNS来授权邮件服务器通过特定电子邮件地址来发送邮件。
第6章，配置主机
解释了如何配置BIND解析器。还讲述了Windows解析器的配置方法。
第7章，BIND的维护
讲述了为了保证区域的平稳运行，管理员所必须要做的定期维护工作，例如检查名称服务器是否正常及其授权情况。
第8章，不断扩展的域
讲述了如何规划区域的发展，包括如何扩大区域，以及如何为迁移和停机做准备。
第9章，子域的划分及管理
探索了成为父区域的乐趣。解释了何时应该成为父区域（创建子域），如何为子域命名，如何创建子域以及如何监控它们。
第10章，高级功能
涉及了一些不常用的名称服务器配置选项，这些选项能够帮助优化名称服务器的性能，并使其易于管理。
第11章，安全防护
讲述了如何保护名称服务器，以及如何配置名称服务器以应对Internet防火墙，还讲述了DNS的两个新增的安全性功能：DNS安全性扩展和事务签名。
第12章，nslookup和dig
详细介绍了最常用的DNS调试工具，包括从远程名称服务器挖掘模糊信息的技术。
第13章，阅读BIND调试输出
BIND的调试信息就像罗塞塔石碑（Rosetta stone）上的文字那样神秘。本章将帮助读者理解由BIND所产生的神秘调试信息的含义，这反过来也将帮助读者更好地了解自己的名称服务器。
第14章，DNS和BIND排错
涵盖了许多常见的DNS和BIND问题及其解决方法，还讲述了一些不常见的、难以诊断的情况。
第15章，使用解析器和名称服务器库例程来编程
演示了如何在一个C程序或Perl脚本中，使用BIND的解析器例程来查询名称服务器并从中检索数据。还提供了一个用来检查名称服务器正常与否及其授权情况的很有用的（希望如此！）程序。
第16章，架构
展示了一个DNS基础设施的端到端的设计，包括外部名称服务器、转发器以及内部名称服务器。
第17章，其他问题
将所有零散的内容集中到一起。讲解了DNS通配符、通过拨号断断续续地连接到Internet的主机和网络、网络名称编码、其他的记录类型、ENUM、IDN以及Active Directory。
附录A，DNS消息格式和资源记录
包括逐字节地分析在DNS查询和响应中所使用的消息格式，以及当前已定义的资源记录类型的完整清单。
附录B，BIND兼容性矩阵
包括了一个矩阵，列举了常用BIND版本中最重要的功能。
附录C，在Linux上编译与安装BIND
包括了如何在Linux上编译BIND 版的手把手教程。
附录D，顶级域名
列出了目前Internet域命名空间中的顶级域名。
附录E，BIND名称服务器及解析器配置
总结了用来配置名称服务器和解析器的每个参数的语法和语义。
本书主要是针对管理区域及一个或多个名称服务器的系统和网络管理员来写的，不过其内容也同样适用于网络工程师、邮件管理员以及其他一些人。但是，由于不同的读者对于本书各个章节的兴趣各不相同，并且也不会希望必须通读全部17章，才能找到工作中所需要的信息。所以希望下面的阅读指南能够帮助读者计划好阅读本书的方式。
正在建立其第一个区域的系统管理员
首先应该阅读第1章和第2章，以了解DNS的理论知识；接着阅读第3章，了解如何开始以及如何选择一个好的域名；然后阅读第4章和第5章，学习如何建立第一个区域。第6章解释了如何配置主机来使用新建的名称服务器。接下来应该阅读第7章，这一章解释了如何通过建立更多的名称服务器和增加区域数据来充实区域。第12章到第14章讲述了排错的工具和技术。
有经验的管理员
通过阅读第6章来学习如何在不同的主机上配置DNS解析器，以及阅读第7章以了解维护区域的信息，可能会对管理员有所帮助。第8章包括了对规划区域未来发展的指导，对于大型区域的管理员来说这些内容特别有价值。第9章解释了子域的划分及管理，这对于正在考虑此项工作的管理员来说是必须要阅读的。第10章涵盖了BIND 和8.4.7版名称服务器上许多新的、高级的功能。第11章涉及保护名称服务器，这可能是有经验的管理员特别感兴趣的内容。第12章到第14章讲述了排错的工具和技术，这部分内容即使身为高级管理员也同样值得一读。第16章应该有助于管理员从全局上来理解DNS的架构。
未完全连接到Internet的网络上的系统管理员
应该阅读第5章来学习如何在此类网络上配置邮件，还应该阅读第11章及第17章来学习如何建立一个独立的DNS基础设施。
程序员
可以阅读第1章和第2章，以了解DNS的理论知识；然后阅读第15章，详细了解如何使用BIND解析器库例程来编程。
不直接负责任何区域的网络管理员
还是应该阅读第1章和第2章以了解DNS的理论知识，然后阅读第12章来学习如何使用nslookup和dig，以及第14章排错技术。
邮件管理员
应该阅读第1章和第2章以了解DNS的理论知识，然后阅读第5章以了解DNS和电子邮件是如何共存的。第12章讲述了nslookup和dig，这对于邮件管理员通过域命名空间来挖掘邮件路由信息也是有帮助的。
感兴趣的用户
可以阅读第1章和第2章来了解DNS的理论知识，接下来，就可以根据喜好随意阅读了！
注意，本书假定读者熟悉基本的UNIX系统管理、TCP/IP网络，以及能够使用简单的shell脚本和Perl来编程。除此之外，本书不要求读者具备任何其他专业知识。当本书引入一个新的术语和概念时，将尽力对其作出定义或解释。只要有可能，本书还会将其与UNIX（以及现实世界）进行类比，以帮助读者进一步理解。
本书中示例程序[2]的电子版可以通过FTP从下列地址获取：
ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z
ftp://ftp.oreilly.com/published/oreilly/nutshell/dnsbind/
无论通过何种方式获得示例程序的压缩包，都可以输入以下命令来解压缩其中的文件：
System V系统需要使用以下tar命令：
如果系统中没有zcat，那么可以分别使用uncompress和tar命令。
如果无法直接通过Internet来获取这些示例，但是可以发送和接收电子邮件，那么可以使用ftpmail来得到它们。要想了解如何使用ftpmail，则可以向ftpmail@online. oreilly.com发送一封无主题且正文只有一个单词“help”的电子邮件。
如果你想就本书发表评论或有任何疑问，敬请联系出版社：
美国：
O’Reilly Media Inc.
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
我们还为本书建立了一个网页，其中包含了勘误表、示例和其他额外的信息。你可以通过如下地址访问该网页：
http://www.oreilly.com/catalog/9780596100575
关于本书的技术性问题或建议，请发邮件到：
bookquestions@oreilly.com
欢迎登录我们的网站（http://www.oreilly.com），查看更多我们的书籍、课程、会议和最新动态等信息。
Facebook: http://facebook.com/oreilly
Twitter: http://twitter.com/oreillymedia
YouTube: http://www.youtube.com/oreillymedia
提示
这个图标用来强调一个提示、建议或一般说明。
警告
这个图标用来说明一个警告或注意事项。
本书的目的是为了帮助读者完成工作。一般而言，你可以在你的程序和文档中使用本书中的代码，而且也没有必要取得我们的许可。但是，如果你要复制的是核心代码，则需要和我们打个招呼。例如，你可以在无需获取我们许可的情况下，在程序中使用本书中的多个代码块。但是，销售或分发O’Reilly图书中的代码光盘则需要取得我们的许可。通过引用本书中的示例代码来回答问题时，不需要事先获得我们的许可。但是，如果你的产品文档中融合了本书中的大量示例代码，则需要取得我们的许可。
在引用本书中的代码示例时，如果能列出本书的属性信息是最好不过。一个属性信息通常包括书名、作者、出版社和ISBN。例如：“DNS and BIND, Fifth Edition, by Cricket Lliu and Paul Albitz (O’Reilly). Copyright 2006 O’Reilly Media, Inc., 0-596-10057-4.”
在使用书中的代码时，如果不确定是否属于正常使用，或是否超出了我们的许可，请通过permissions@oreilly.com与我们联系。
当读者在最喜欢的技术书籍的封面上看到Safari®Enabled图标时，则意味着此书可以通过O’Reilly网络的Safari书架来在线获得。
Safari提供了一个比电子书更好的解决方案。它是一个虚拟的图书馆，能够让读者轻松地搜索成千上万的顶级科技书籍，剪切和粘贴代码示例，下载章节，并且在需要最准确、最新的信息时能够快速找到答案。可以访问http://safari.oreilly.com来免费试用。
每一章开头的引语，节选自古腾堡计划（Project Gutenberg）中，千年支点（Millennium Fulcrum）2.9版《爱丽丝梦游仙境》和1.7版《镜中世界》（这两本书都是由Lewis Carroll所著）的电子文本。其中，第1、2、5、6、8章以及第14章的引语来自于《爱丽丝梦游仙境》，第3、4、7、9、13、15章以及第17章的引语来自于《镜中世界》。
非常感谢Ken Stone、Jerry McCollom、Peter Jeffe、Hal Stern、Christopher Durham、Bill Wisner、Dave Curry、Jeff Okamoto、Brad Knowles、K. Robert Elz和Paul Vixie对于本书所做的宝贵贡献。作者也同样感谢其审稿人：Eric Pearce、Jack Repenning、Andrew Cherenson、Dan Trinkle、Bill LeFebvre和John Sechrest提出的批评和建议。如果没有他们的帮助，那么这本书就不会像现在这样（它会更短！）。
对于第2版，作者还要感谢其杰出的审核小组：Dave Barr、Nigel Campbell、Bill LeFebvre、Mike Milligan和Dan Trinkle。
对于第3版，作者要向其技术审核“梦之队”致敬：Bob Halley、Barry Margolin和Paul Vixie。
对于第4版，作者要感谢Kevin Dunlap、Edward Lewis和Brian Wellington，他们是最优秀的审核团队。
对于第5版，作者要感谢其优秀的技术审核小组：João Damas、Matt Larson和Paul Vixie，以及Silvia Hagen在最后关头对IPv6所做的帮助。
Cricket特别要感谢他的前任经理——Rick Nordensten，一个现代惠普经理的典范，他阅读了这本书的第一个版本；感谢他的邻居，能够长期容忍其偶尔暴躁的脾气；当然还要感谢他的妻子Paige，她不仅给予了作者不懈的支持，还容忍了他在她睡觉时敲键盘的声音。对于第2版，Cricket还要对其另外两位前任经理——Regina Kershner和Paul Klouda说一声“谢谢你们”，感谢他们支持Cricket从事Internet工作。对于第3版，Cricket要向其合作伙伴——Matt Larson，表示衷心的感谢，感谢他为共同开发Acme Razor所做的工作。对于第4版，Cricket要感谢他忠诚的、毛茸茸伙伴——Dakota和Annie，感谢它们的亲吻和陪伴，以及Walter B，他时不时地将头伸进办公室来检查他爸爸的工作。对于第5版，他必须感谢Baby G。并且，他还对在Infoblox公司的朋友和同事辛勤的工作、慷慨的支持以及他们的陪伴表示诚挚的谢意。
Paul要感谢他的妻子——Katherine，感谢她对于他需要参加许多次的审核的耐心，并证明她可以在闲暇之余，比她的丈夫写完他那半本书更快地做好一床被子。
[1] 并且，如果使用的是IPv6，这个数字更长达128位，或者说是一个从0～39位的十进制数之间的数字。
[2] 示例也通过http://examples.oreilly.com/dns5在线提供。
Cricket Liu毕业于加州大学伯克利分校，那里是言论自由的堡垒，有随意获取的UNIX和便宜的比萨饼。毕业之后，他加入了HP公司，并在里面工作了9年。
加州Loma Prieta发生地震后，hp.com区域的管理部分被迫从HP实验室转移到HP公司办公室（因为洪水淹没了计算机实验室），于是Cricket开始负责hp.com区域的管理工作。Cricket负责hostmaster@hp.com长达3年之久，然后他加入了HP的Professional Services Organization，创立了HP的互联网咨询项目（Internet Consulting Program）。
他于1997年离开HP公司，与好友Matt Larson（也是本书的合作作者）成立了Acme Byte & Wire公司，专门提供DNS咨询与培训服务。Network Solutions在2000年6月买下Acme，同一天Acme并入VeriSign公司。Cricket在VeriSign公司的全球注册服务部门（Global Registry Services）的DNS产品管理部当了一年的主管。
2003年3月，Cricket进入了Infoblox，这是一家开发DNS和DHCP产品的公司，目前他是该公司的架构副主管（Vice President of Architecture）。
Cricket与他的妻子Paige，他们的儿子Walt和女儿Greta，以及两只西伯利亚爱斯基摩犬Annie和Dakota，一起生活在加州。
Paul Albitz是HP公司的软件工程师。他在威斯康辛大学克罗斯分校获得科学学士学位，在普渡大学获得科学硕士学位。
Paul曾为HP-UX 7.0和8.0移植BIND。在此期间，他为hp.com域开发了运维工具。从那时起，Paul在他19年职业生涯中参与了多种不同的HP产品设计：HP JetDirect软件、HP OfficeJet fax软件、the HPPhoto站点和HP Photosmart Premier软件。
Paul和他的妻子Katherine以及两只猫Gracie和Tiffany，生活在加州圣地亚哥。
本书的封面动物是蝗虫。蝗虫遍布全球。在5000多个种类中，约有100种分布在北美洲。蝗虫身体是绿褐色的，长度从0.5～4英寸不等，翅膀展开时可达6英寸。它们的身体可以分为三个部分：头部、胸廓和腹部，有三对足和两对翅膀。
雄性蝗虫使用它们的后足与前翅发出“啾啾”的声音。它们的后足有一个突出物，与坚硬前翅相互摩擦，发出人耳能够听得到的声音，与弓弦发音原理一样。
蝗虫是农作物的主要害虫，尤其当它们成群结队时。一只蝗虫一天可以吃掉30毫克食物。当蝗虫爆发时，在一平方英尺的范围内，通常会聚集50只甚至更多的蝗虫，它们可以吃掉相当于一头牛每天吃掉的一英亩草地。蝗虫除了吃叶子，还会攻击植物最脆弱的根茎，从而导致植物折断。 封面图像来自Dover Pictorial Archive。
白兔子戴上它的眼镜，问道：“陛下，我该从何说起？”
“从头开始，”国王一本正经地说道，“一直到结束，然后停止。”
要想理解域名系统（Domain Name System，DNS），最好先了解一些ARPAnet的历史。DNS开发的目的是为了解决ARPAnet上的一些特殊问题，但是由ARPAnet发展而来的Internet却仍然是DNS的主要使用者。
如果已经使用了多年的互联网，则可以跳过这一章。否则，阅读本章能够提供足够的背景知识，以便理解是什么推动了DNS的发展。
20世纪60年代末期，美国国防部高级研究计划局（Department of Defense’s Advanced Research Projects Agency，即ARPA，也是后来的DARPA），开始资助建立ARPAnet——一个试验性的计算机网络，用以连接美国各重要研究部门。组建ARPAnet的最初目的是为了让政府部门共享昂贵且稀缺的计算机资源。然而，ARPAnet的用户一开始就通过该网络进行合作，合作的范围涉及共享文件与软件，交换电子邮件以及通过共享远程计算机进行联合研发。
TCP/IP（Transmission Control Protocol/Internet Protocol，传输控制协议/Internet协议）协议族开发于20世纪80年代初期，之后迅速发展成为ARPAnet上主机之间的标准网络协议。流行的BSD UNIX（由加州大学伯克利分校所开发）操作系统内含了该协议族，这对于网络互联的普及起了很大作用。因为BSD UNIX操作系统对于大学来说实际上是免费的。这就意味着对于那些先前未接入ARPAnet的组织，网络互联和连接到ARPAnet的费用突然便宜了很多。许多原先连接到ARPAnet上的计算机也连接到本地局域网（LAN）上。很快，局域网上的其他计算机也开始通过ARPAnet进行通信。
连接网络的主机数量从原来的屈指可数，发展到成千上万。原来的ARPAnet成为基于TCP/IP的本地和区域网络的主干，被称为Internet。
然而在1988年，DARPA决定终止ARPAnet的试验计划。美国国防部开始拆除ARPAnet。由美国国家科学基金会资助的另一个网络NSFNET，取代了ARPAnet成为Internet的主干。
在1995年的春天，Internet从由公共资金资助的NSFNET作为主干的网络，转变成为使用多个商业主干的网络。这个商业主干网络由诸如SBC和Sprint这样的电信公司，以及诸如MFS和UUNET这样历史悠久的商业网络互联者共同运营。
今天，Internet连接着世界各地数以百万计的主机。事实上，全世界有相当一部分的非PC计算机连接在Internet上。一些商业主干网具有每秒数千兆的容量，这个带宽是起初ARPAnet的上万倍。每天都有成千上万的人通过网络进行通信与合作。
大部分人认为，Internet与internet没什么区别。从书写上看，两者的区别很小：一个首字母大写，而另一个首字母小写。但是两者的含义却是迥然不同的。首字母大写的Internet，指的是基于ARPAnet建立起来并沿用至今的，成为所有直接或间接连接到美国商业主干网的，使用TCP/IP协议的网络。更深入来看，Internet实际上是由许多不同的网络，如商业的TCP/IP主干、企业网络、美国政府网络以及其他国家的TCP/IP网络通过高速数字线路连接而成的。而internet，则是由多个使用同一网络互联协议的小型网络组成的任何网络。该类型的网络不一定与Internet相连接，也不一定使用TCP/IP作为其网络协议，比如一些公司的内部独立网络。
至于intranet，实际上就是一个基于TCP/IP协议的internet，用来强调在公司内部网络上使用了Internet上发展和流行起来的技术。另一方面，extranet则指的是基于TCP/IP协议的internet，用以连接合作公司、经销商、供应商及客户沟通平台。
在20世纪70年代，ARPAnet是一个只有几百台主机的小型、友好的社区。所以只需要HOSTS.TXT这一个文件，就可以包含连接到ARPAnet的每台主机的名称到地址的解析。人们所熟知的UNIX主机表（/etc/hosts）就是由HOSTS.TXT演变而来的（主要是删除了UNIX不用的字段）。
HOSTS.TXT文件由SRI的网络信息中心（Network Information Center，NIC）负责维护，并且由一台单独的主机SRI-NIC[1]来负责分发。ARPAnet的管理员通常将改动通过电子邮件传达给NIC，并定期通过FTP的方式连接到SRI-NIC，以获取最新的HOSTS.TXT文件。他们每周会进行一次或者两次更新，将改动编译成一个新的HOSTS.TXT文件。随着ARPAnet的成长，这种方案就不可行了。HOSTS.TXT文件的大小随着ARPAnet上主机数量的增长而不断变大。此外，更新过程所造成的网络流量也增加得越来越快：每新增一台主机不仅仅意味着在HOSTS.TXT文件中增加一行，还意味着其他主机需要通过SRI-NIC获取更新。
当ARPAnet采用了TCP/IP协议后，网络用户出现了激增。这让使用HOSTS.TXT的主机面临以下诸多问题。
流量和负载
由于分发HOSTS.TXT文件所引起的网络流量和处理器负载，使得SRI-NIC的文件分发变得让人难以忍受。
名称冲突
在HOSTS.TXT文件中不应该出现两台名称相同的主机。然而，NIC虽然能够在分配地址时确保其唯一性，但是却没有管理主机名称的权利。NIC无法防止有人添加一台使用重复名称的主机，从而打乱整个机制。例如，添加一台与邮件中心（mail hub）同名的主机将会破坏ARPAnet上的大部分邮件服务。
一致性
在一个不断扩展的网络上，维持HOSTS.TXT文件的一致性变得越来越困难。在新的HOSTS.TXT文件传达到庞大的ARPAnet的最远角落之前，可能某台主机的地址已经发生了改变，或者又有一台新的主机出现了。
最根本的问题在于，HOSTS.TXT机制的扩展性不好。具有讽刺意味的是，ARPAnet试验的成功却导致了HOSTS.TXT机制的失败和淘汰。
ARPAnet的管理者们开始研究HOSTS.TXT机制的接替者。他们的目标是创建一个系统，能够解决集中管理主机表所造成的问题。新的系统应当允许在本地管理数据，同时又使数据在全世界范围内可用。管理的分散化将终结单一主机所产生的瓶颈，缓解网络的流量问题。本地管理也会使保持数据的更新变得容易很多。新系统将采用层次结构的命名空间来为主机命名。这样就能确保名称的唯一性。
南加州大学信息科学研究所（USC’s Information Sciences Institute）的Paul Mockapetris负责设计这个新系统的体系结构。1984年，他发布了RFCs 882和883，用以描述DNS。这些RFC后来被RFC 1034和1035所取代，也就是现在的DNS规范[2]。目前，RFC 1034和1035已经被许多其他的RFC所扩充，扩充部分包括：DNS潜在的安全问题、实现问题、管理缺陷、名称服务器的动态更新机制以及保证区域数据的安全性，等等。
域名系统是一个分布式数据库。这种结构允许对整体数据库的各个部分进行本地控制，并且在各个部分中的数据通过客户端/服务器（client/server）模式变得对整个网络都可用。通过复制和缓存等机制，DNS拥有了健壮性和充足的性能。
被称为名称服务器（nameserver）的程序构成了DNS客户端/服务器机制的服务器一端。名称服务器包含了数据库中某些部分的信息，并使得这些信息对被称为解析器（resolver）的客户端可用。解析器通常只是一组库例程（library routine），这些库例程产生查询请求并将请求通过网络发送给名称服务器。
如图1-1所示，DNS数据库的结构类似于UNIX文件系统的结构。整个数据库（或者文件系统）被描绘成一棵倒置的树，root节点在树的顶端。树中的每个节点都有一个文本标签，用来标识该节点同父节点的相对关系。这大致上类似于文件系统中的“相对路径（relative pathname）”，例如bin。空标签（null label）或“ ”被保留给root节点使用。在本书中，root节点被写成一个点号（.）。而在UNIX的文件系统中，根目录则被写成一个斜杠（/）。
图1-1 DNS数据库同UNIX文件系统的比较
整棵树上的各个节点也是其所对应的新子树的根。每棵子树都代表了整个数据库的一部分：对于UNIX文件系统而言代表着一个目录（directory），而对于域名系统而言则代表着一个域（domain）。每个域或目录又可以被进一步划分为额外的部分，在DNS中这被称作子域（subdomain），而在文件系统中这被称作子目录（subdirectory）。像子目录一样，子域在图中被描绘成它们父域的孩子。
和每个目录一样，每个域都有一个唯一的名称。一个域的域名标识了它在数据库中的位置，就像一个目录的绝对路径名（absolute pathname）标识了它在文件系统中的位置一样。在DNS中，域名是从该域的root节点开始，一直回溯到整棵树的root节点的标签序列，以点号（.）分隔路径中的各个节点标签。在UNIX文件系统中，一个目录的绝对路径是从树的根节点开始标记，一直走到叶子为止，使用斜杠“/”来分隔各个名称（同DNS的方向正好相反，见图1-2）。
图1-2 在DNS和UNIX文件系统中读名称的方法
在DNS中，每个域都可以被分解成若干个子域，这些子域可以被分派给不同的组织。比方说，一个名叫EDUCAUSE的组织管理着edu（educational）域，但是却委托加州大学伯克利分校管理berkeley.edu子域（如图1-3所示）。这就好像挂载（mount）一个远程文件系统一样。文件系统中的某些目录，实际上可能是位于其他主机上的文件系统，因为它们挂载自远程主机。例如（如图1-3所示），主机winken的管理员负责管理本地主机上以usr/nfs/winken目录出现的文件系统。
图1-3 子域和文件系统的远程管理
要将berkeley.edu授权给加州大学伯克利分校，需要创建一个新的区域（zone），就是在域命名空间中划分出一段可以自治的区域。berkeley.edu现在已经从edu中独立出来，它包括了所有以berkeley.edu结尾的域名。从另一方面来说，edu区域仅仅包括以edu结尾的域名，但又不包括像berkeley.edu这样已经被授权出去的域名。berkeley.edu可以被进一步划分出子域，例如cs.berkeley.edu。与此同时，如果berkeley.edu的管理员将部分子域的管理权委托给其他组织，那么这些子域也可以成为独立的区域。如果cs.berkeley.edu是一个独立的区域，那么berkeley.edu区域中将不包括以cs.berkeley.edu结尾的域名（见图1-4）。
域名被当做DNS数据库的索引来使用。可以把域名同DNS中的数据对应起来。在文件系统中，目录包含文件和子目录。同样，域也包含主机和子域。域中所包含的主机和子域的域名，就位于该域所属的命名空间的子树中。
图1-4 edu、berkeley.edu以及cs.berkeley.edu区域
在网络上的每台主机都有一个域名，它指向该主机的相关信息（见图1-5）。这些信息中可能包含IP地址、邮件路由信息等。此外，主机也可以拥有一个或多个域名别名（domain name aliases），这些域名别名是从某个域名（别名）指向另一个域名（正式的或规范的域名）的指针。在图1-5中，“mailhub.nv...”就是别名，而它的规范名称是“rincon.ba.ca...”。
图1-5 DNS中别名指向规范名称
为什么要采用如此复杂的结构呢？这是为了解决HOSTS.TXT文件所存在的问题。例如，采用层次结构的域名是为了消除名称冲突的问题。每个域都有一个唯一的域名，因而管理这个域的组织可以自由地命名该域中的主机和子域。无论管理者为他们的主机或者子域选择什么样的名称，都不会和其他组织的域名相冲突，因为这些名称会有唯一的域名附加在结尾。例如，管理hic.com的组织，可以把一台主机命名为puella（如图1-6所示），因为这个组织知道这台主机将会以hic.com结尾，从而成为一个唯一的域名。
图1-6 解决名称冲突问题
Paul Mockapetris亲自创建了第一个域名系统，名叫JEEVES。在此之后被实现的域名系统是BIND（Berkeley Internet Name Domain的缩写），它是由Kevin Dunlap为伯克利的4.3版BSD UNIX系统所编写。BIND现在由Internet Systems Consortium负责维护[3]。
BIND就是本书所讨论的DNS的实现，也是迄今为止普及最广的DNS实现。它不仅被移植到各个版本的UNIX上，成为大多数UNIX系统的标准配置而被封装于系统中，更是被Microsoft的Windows NT、Windows 2000及Windows Server 2003所采用。
尽管DNS很实用，但是仍然存在不需要使用DNS的情况。除了DNS以外还有其他的名称解析（name-resolution）机制，其中的一些可能还是某些操作系统的标准组件。有时管理区域和名称服务器的花费要远远超过它的收益。另一方面，在某些情况下，除了建立和管理名称服务器之外别无选择。下面有一些能够帮助做出决定的指引。
如果已经连接到了Internet……
那么DNS是必需的功能。DNS可以看作是Internet上的通用语言：几乎所有Internet上的网络服务都使用了DNS。这些服务包括Web、电子邮件、远程终端访问以及文件传输。
另一方面，这并不一定意味着必须亲自建立和管理自己的区域。如果只拥有少量的主机，则可以加入一个现有的区域（参考本书第3章），或者可以找别人协助管理区域。如果是付费经由Internet服务提供商（Internet service provider，简称ISP）接入Internet的，则可以询问他们是否也会协助管理该区域。即使不是Internet服务提供商的顾客，市场上也还有其他的公司可以提供帮助，当然代价是需要支付一定的费用。
如果已拥有为数不少的主机，则可能会希望拥有自己的区域。如果想直接管控自己的区域和名称服务器，那么请继续往下阅读！
如果拥有自己的基于TCP/IP协议的internet……
那么可能会需要DNS。这里所说的internet，并不仅仅指使用TCP/IP协议将工作站连接起来的一个以太网（如果有这种感觉，则请参阅下一节的说明）；其真正的意思是一个相当复杂的“由许多网络相连而组成的网络”。例如，或许拥有数十个通过路由器连接在一起的以太网段。
如果该internet基本上是一个同构的网络，而其中的主机又不需要DNS（这些主机并不使用TCP/IP协议），那就可以不使用DNS。但是如果拥有各式各样的主机，尤其是某些主机运行了不同版本的UNIX系统，这时就可能会需要DNS。它将简化主机信息的分发，消除可能会遇到的各种不同主机表分发机制的麻烦。
如果拥有自己的本地区域网络或者站点网络……
如果该网络没有连接到更大的网络上，那么就可能不需要使用DNS了。可以考虑使用Microsoft的Windows Internet名称服务（Windows Internet Name Service，WINS）、主机表或是Sun公司的网络信息服务（Network Information Service，NIS）等产品。
但是如果需要分布式的管理，或者在保持网络数据的一致性上有困难，那么DNS可能就是为此准备的。假如该网络很快就要连接到另一个网络上（比如公司的internet，或者是Internet），那么现在就着手建立自己的区域将会是明智之举。
[1] SRI是位于加州门洛帕克（Menlo Park）的斯坦福研究院（Stanford Research Institute）的前身，SRI的研究领域很广泛，其中也包括计算机网络。
[2] RFC是请求评议文件（Request for Comments documents）的简称，这是Internet上引进新技术的相对非正式过程的一部分。RFC通常免费发布，对技术应用进行了大量技术性的描述，RFC通常是为技术的实现者所准备的。
[3] 更多有关Internet Systems Consortium及BIND相关信息，请参阅http://www.isc.org/sw/bind/。
