本节书摘来自异步社区《DNS与BIND（第5版）》一书中的第4章，第4.2节,作者： 【美】Joseph Davies 更多章节内容可以访问云栖社区“异步社区”公众号查看。
4.2 建立区域数据
建立电影大学名称服务器的第一步，是将主机表转换成等效的DNS区域数据。该数据的DNS版本有多个文件。一个文件将所有主机名映射成地址。其他文件将地址映射回主机名。名称到地址（name-to-address）的查询有时被称作正向解析（forward mapping），而地址到名称（address-to-name）的查询则被称作逆向解析（reverse mapping）。每个网络都拥有自己的逆向解析数据文件。
作为本书的一个约定，将主机名映射到地址的文件称作db.DOMAIN。例如，对于movie.edu来说，这个文件就是db.movie.edu。而将地址映射到主机名的文件称作db.ADDR，这里的ADDR是去掉尾部的0或者规范的网络掩码的网络号。在这个例子中，文件应被称作db.192.249.249以及db.192.253.253；每个网络都会有一个对应的文件。（这里的db是database的简写。）本书将db.DOMAIN和db.ADDR文件统称为区域数据文件（zone datafile）。还有一些其他的区域数据文件：db.cache以及db.127.0.0。这两个文件是系统必备的。每个名称服务都必须具备这两个文件，而且这两个文件对于每个服务器而言也都大同小异。
为了将所有的区域数据文件绑定在一起，名称服务器需要一个配置文件；对于BIND 8和9来说，这个文件通常被称为named.conf。区域数据文件的格式对于所有的DNS实现都是一样的：它被称作主文件格式（master file format）。另一方面，配置文件的格式只与名称服务器的实现（这里是BIND）有关。
4.2.1 区域数据文件
区域数据文件中的大部分条目被称为DNS资源记录（DNSresource record）。DNS查询是不区分大小写的，因此在区域数据文件中可以使用大写、小写或者大小写混合来输入名称。本书推荐全部使用小写。无论如何，即使查询是不区分大小写的，但还是应该保持其一致性。例如，如果将Titanic.movie.edu记录增加到区域数据中，那么人们查询titanic.movie.edu时将会找到该记录，只是域名中包含了一个大写的“T”。
资源记录必须从一行的第一列开始。本书示例文件中的资源记录也是从第一列开始的，但可能因为本书的排版格式而看起来缩进了。在DNS的RFC中，资源记录都是按照某种特定的顺序排列的。大多数人都选择使用这样的顺序，本书也是如此，但这不是硬性的要求。区域数据文件中资源记录的顺序如下。
SOA记录
指明该区域的权威。
NS记录
列出该区域的名称服务器。
Other记录
有关该区域中主机的数据。
本章将会提到的其他记录包括以下三个。
A
名称到地址的映射。
PTR
地址到名称的映射。
CNAME
规范名称（将别名映射到规范名称）。
毫无疑问，那些对主文件格式有一定经验的人，在查看我们的数据时可能会对自己说：“使用其他方式的话，会更简短一些……”本书没有在区域数据中使用缩写或简写，至少最初没有，这样读者就能理解每个资源记录的完整语法。一旦理解了完整的写法之后，本书就会回过头来以更简洁的方式来呈现这些文件了。
4.2.2 注释
如果含有注释和空行，区域数据文件将更容易被阅读。注释以分号开始，到一行的结尾处为止。正如猜想的那样，名称服务器会忽略注释和空行。
4.2.3 设置区域的默认TTL
在开始写我们的区域数据文件之前，得先弄清正在运行的BIND版本。（要找出BIND的版本，可以使用named -v。如果无法识别-v选项，那么所使用的BIND很可能是8.2之前的版本。）因为设置区域默认TTL的方式在BIND 8.2中发生了变化，所以不同的版本之间会有差异。BIND 8.2之前的版本，用SOA记录的最后一个字段来设置区域的默认TTL值。但就在BIND 8.2快问世之前，RFC 2308发布了，它将SOA记录的最后一个字段的意义改成了否定缓存TTL（negative caching TTL）。否定缓存TTL指的是远程名称服务器将区域的否定响应（negative response）缓存多长的时间，而否定响应指的是在所查询的特定域名或特定域名的数据类型不存在时做出的应答。
那么，如何在BIND 8.2及其后续版本中设置区域的默认TTL呢？可以使用新的$TTL控制语句。$TTL语句可以用来指定在该语句之后（但在其他$TTL语句之前），所有未明确指定TTL的记录的生存时间。
名称服务器会在查询响应中提供这个TTL，以便其他的服务器能够根据TTL所指定的时间来缓存数据。如果数据变动不频繁，则可以考虑将TTL的默认值设置成数天。一周大概是有意义的最长时间了。还可以使用短至几分钟的值，但考虑到由此导致的DNS流量，本书不推荐将TTL设置成0。
因为我们运行的是新版本的BIND，所以需要使用$TTL语句来设置区域的默认TTL。3个小时看起来正合适，所以区域数据文件的开头如下：
如果正在运行的名称服务器上使用的是BIND 8.2之前的版本，那么就不要尝试添加$TTL语句：名称服务器非但不会识别该语句，而且还会把它当成语法错误。
4.2.4 SOA记录
区域数据文件中的下一个设定项就是SOA（start of authority，起始授权机构）资源记录了。SOA记录被用来指出哪个名称服务器是此区域数据的最佳信息来源。由于有了该SOA记录，我们的名称服务器就成为movie.edu区域的权威名称服务器。每个db.DOMAIN和db.ADDR文件中都要有一个SOA记录。在一个区域数据文件中可以有一个SOA记录，并且只能有一个。
将下面的SOA记录加入到db.movie.edu文件中：
名称movie.edu.必须从文件的第一列开始。确保名称以“.”结尾，否则将会产生令人惊讶的结果！（本章稍后会解释原因。）
上面的IN代表Internet，是一种数据类（class）；还有其他的类存在，但都没有被广泛使用。本书的例子只使用IN类。类字段是可选的。如果未设定此字段，则名称服务器会根据（指示其读取该文件的）配置文件中的语句来决定类。本章稍后还将讨论。
跟在SOA之后的第一个名称（toystory.movie.edu.）是movie.edu的primary名称服务器的名称。第二个名称（al.movie.edu.）是区域负责人的邮件地址（如果把第一个“.”替换成“@”的话）。通常所看到的电子邮件地址多以root、postmaster或hostmaster作为收件人名称。名称服务器不要使用这些地址；它们是给负责人使用的。如果对某个区域有疑问，可以向SOA记录所列出负责人的电子邮件地址发送信息。BIND还提供了另一种资源记录类型，即RP（responsible person，负责人），它的用途也是这样。本书将在第7章中讨论RP记录。
圆括号可以让SOA记录跨越多行。SOA记录中圆括号内的大部分字段是供slave名称服务器使用的，在本章稍后介绍slave名称服务器时再讨论。现在把它们当成合理的数值就行了。
还要将类似的SOA记录添加到文件db.192.249.249和文件db.192.253.253的开头。在这些文件中，SOA记录中的第一个名称要从movie.edu.改成相应的in-addr.arpa区域的名称：分别是249.249.192.in-addr.arpa.和253.253.192.in-addr.arpa.。
4.2.5 NS记录
每个文件中都需要增加的另一个条目是NS（nameserver）资源记录。需要为区域的每个权威名称服务器都添加一条NS记录。下面是db.movie.edu文件中的NS记录：
这些记录指明了movie.edu区域有两个名称服务器。这两个名称服务器分别运行在主机toystory.movie.edu和主机wormhole.movie.edu之上。因为像wormhole.movie.edu这样的多宿主主机（Multi-homed host）有着非常好的网络连接性，所以拿它们来运行名称服务器是个极好的选择。换句话说，多宿主主机可以被不同网络上的主机直接访问，它们还会被严密监控，所以不容易出问题。本书第8章将会更详细地讨论应该在何处放置名称服务器。
同SOA记录一样，也需要将NS记录添加到db.192.249.249和db.192.253.253文件中。
4.2.6 地址和别名记录
下面将创建名称到地址的映射。将下面的资源记录添加到db.movie.edu文件中：
前两块内容应该不会让人觉得奇怪。A代表地址（address），每条资源记录将一个名称映射成一个地址。wormhole.movie.edu是一个多宿主主机，它拥有两个与名称相对应的地址，因此就有两条地址记录。与主机表查询不同的是，对于一个名称，DNS查询可以返回多个地址；例如，查询wormhole.movie.edu时就会返回一个以上的地址。如果查询者和名称服务器位于同一个网络，某些名称服务器会将离查询者距离最近的地址放在应答的最前面，以获得更好的性能。这种特性被称作地址排序（address sorting），本书将在第10章予以介绍。如果没有采用地址排序，那么这些地址就会在每次查询后被轮转（rotate），因此会导致后来的响应以不同的顺序列出这些地址。这种特性被称作轮询调度（round robin），本书也将在第10章中更加详细地讨论。
第三块内容包含了主机表的别名。在前三个别名中，创建的是CNAME（canonical name，规范名称）资源记录。然而，另外两个别名创建的却是地址记录（稍后会继续讨论）。CNAME资源记录将别名映射到规范名称。名称服务器处理CNAME记录的方式和主机表中处理别名的方式不同。当名称服务器查找一个名称却发现了一个CNAME记录时，它会用规范名称替代原先的别名，然后查找这个新的名称。例如，当名称服务器查找wh.movie.edu时，发现了一个指向wormhole.movie.edu的CNAME记录，接着它会查找wormhole.movie.edu，并返回两个地址。
对于toys.movie.edu这样的别名，有件事必须牢记：别名绝对不能出现在资源记录的右边。换句话说，资源记录的数据部分应该始终使用规范名称（例如，toystory.____movie.edu）。请注意，前面刚创建的NS记录使用的就是规范名称。
最后的两个条目解决了一个特别的问题。假设拥有一个像wormhole.movie.edu那样的多宿主主机，并且希望检查其中的一个接口。一个常用的故障诊断技术是ping该接口以验证是否有响应。如果ping的是wormhole.movie.edu这个名称，那么名称服务器将返回该名称的两个地址。ping程序会使用响应列表中排在第一位的地址，但哪个地址会被排在前面呢？
有了主机表，就可以通过wh249.movie.edu或wh253.movie.edu来选择想要的地址；这两个名称分别对应着主机的一个地址。为了给DNS提供相同的功能，这里没有将wh249.movie.edu和wh253.movie.edu设置成别名（CNAME记录）。否则在通过别名来查询时，会返回wormhole.movie.edu的两个地址。所以这里使用了地址记录。现在要检查wormhole.movie.edu上192.253.253.1接口的运行情况，直接ping wh253.movie.edu就可以了，因为它指向了一个唯一的地址。同样的情况也适用于wh249.movie.edu。
把这作为一条通用的规则来说就是：如果一台主机是多宿主的（拥有不止一个网络接口），先创建一个地址（A）记录让每个别名唯一对应一个地址，然后再为那些对所有地址都通用的别名创建CNAME记录。
现在，不要把像wh249.movie.edu和wh253.movie.edu这样的名称告诉用户。这些名称只用于系统管理。如果用户知道了像wh249.movie.edu这样的名称，当在某些地方（例如.rhosts文件中）无法使用这些名称时，他们就会感到很困惑。不能使用的原因是：这些地方需要通过查询地址来得到规范名称，如wormhole.movie.edu。
由于使用了A（地址）记录来设定wh249.movie.edu和wh253.movie.edu这两个别名，因此可能会产生这样一个疑问：“在任何情况下都可以使用地址记录来代替CNAME记录吗？”嗯，在大多数的应用程序中用地址记录来代替CNAME记录不会产生问题，因为这些应用程序只关心是否找到了对应的IP地址。但是有一种应用程序——sendmail，就不是这样的。sendmail通常会将邮件头部的别名替换成规范名称；这样的标准化过程只在邮件头部的名称关联到CNAME数据时才会发生。如果没有为别名创建CNAME记录，则sendmail就必须清楚主机所有可能为外界知道的别名，这需要对sendmail进行额外的配置。
除了sendmail的问题，当用户尝试弄明白.rhosts文件中的规范名称时，可能也会感到疑惑。在查找拥有CNAME数据的名称时，用户会被带往其所对应的规范名称，而在查找拥有地址数据的名称时却不会。在这种情况下，用户应当通过查找IP地址来获得规范名称，就像rlogind所做的那样，但如此聪明的用户似乎永远也不会出现在我们管理的系统中。
4.2.7 TR记录
接下来，将要创建地址到名称的映射。db.192.249.249文件将网络192.249.249/24中的地址映射到主机名。此时所使用的DNS资源记录就是PTR（pointer，指针）记录。在这个网络上，每个网络接口都有一个对应的PTR记录。（回忆一下，在DNS中地址会被当作名称来查询。此时地址被反过来，并在后面附加上in-addr.arpa。）
下面是我们为网络192.249.249/24所添加的PTR记录：
对于上面的数据有几点需要注意。首先，地址应该指向单一名称：规范名称。因此192.249.249.1会映射到wormhole.movie.edu，而不是wh249.movie.edu。可以创建两个PTR记录，一个指向wormhole.movie.edu，另一个指向wh249.movie.edu，但是大多数软件还不能支持一个地址对应着多个名称。其次，即使wormhole.movie.edu拥有两个地址，在这里也只能看到其中的一个。这是因为这个文件只显示在网络192.249.249/24上的地址，对于wormhole.movie.edu来说只有一个地址在该网络上。
同时，也要为网络192.253.253/24创建类似的数据。
4.2.8 完整的区域数据文件
现在已经讲解了区域数据文件中的各种资源记录，接下来将要展示的是所有数据整合在一起时的样子。再次提醒，这些资源记录实际的排列顺序并不重要。
下面是db.movie.edu文件中的内容：
下面是db.192.249.249文件中的内容：
下面是db.192.253.253文件中的内容：
4.2.9 环回地址
名称服务器还需要一个额外的db.ADDR文件以覆盖环回（loopback）网络：所谓的环回网络是一种特殊的地址，主机用它来将流量引向自己。环回网络通常为127.0.0/24，并且其主机号通常是127.0.0.1。因此，这个文件的名称就是db.127.0.0。这没什么好奇怪的，它看上去和其他的db.ADDR文件一样。
以下是db.127.0.0文件中的内容：
为什么名称服务器需要这个愚蠢的小文件呢？仔细想一下，没有人负责管理127.0.0/24这个网络，而系统却用它来作为环回地址。既然没有人直接负责，那么每个使用这个网络的人都得自己负责管理。可以忽略这个文件，并且名称服务器仍然可以运行。然而，如果查找127.0.0.1就会失败，因为所联系的root名称服务器本身未将127.0.0.1映射到一个名称。为了避免发生意想不到的状况，需要自己提供这一映射。
4.2.10 Root提示（Hint）数据
除了本地信息，名称服务器还需要知道root区域的名称服务器在哪里。这些信息只能从Internet主机ftp.rs.internic.net（198.41.0.6）那里检索到。可以使用匿名FTP从该主机的domain子目录下获取db.cache文件。
域名“.”代表root区域。因为root区域的名称服务器时常有改动，所以不要认为上述列表是最新的。还是去下载个最新版本的db.cache文件吧。
如何才能保持db.cache文件始终是最新的呢？作为网络管理员，这是你的责任。一些老版本的BIND会定期更新这个文件。但是这个功能被禁用了；很明显，它的运行效果没有开发者所设想的那么好。有时，更改过的db.cache文件被发送到bind-users或namedroppers邮件列表（本书第3章有介绍）。如果是这些邮件列表中的一员，那么可能会收到更新后的db.cache文件。
可以在这个文件中放入除了root名称服务器数据之外的其他数据吗？可以，但不会起作用。通常，名称服务器会将这些数据安装到缓存中。虽然“cache file”这个名称未变，但这个文件的用法却发生了微妙的变化。名称服务器会将从这个文件中读来的数据，储存到内存中一个特殊的地方来作为root提示。即使其TTL值降到0，它们也不会像缓存数据那样被丢弃。名称服务器利用这些提示数据来向root名称服务器查询其所缓存的当前root名称服务器列表。当缓存中的root名称服务器列表超时后，名称服务器会再次利用提示数据来获取一个新的列表。
为什么名称服务器在已经拥有了root名称服务器列表的情况下，还要向出现在root提示文件中的名称服务器查询root名称服务器列表呢——也许它自己就是root名称服务器？这是因为虽然这个文件可能已经过时了，但列表中所列出的名称服务器几乎肯定知道当前最新的root名称服务器列表。
3 600 000秒代表着什么呢？它是这个文件中每个记录的显示指定的生存时间。在旧版本中，这个数值是99 999 999。因为这个文件的内容最初是放在缓存中的，所以名称服务器需要知道这些记录被保留的时间。99 999 999秒是个非常长的时间——只要服务器在运行，root名称服务器的数据就一直保存在缓存中。由于现在名称服务器会将这些数据存储在一个特殊的地方，即使超时了也不会丢弃这些数据，所以TTL就显得没有必要了。但是将生存时间设置为3 600 000秒也没什么坏处，这会成为名称服务器的管理者代代相传的关于BIND的有趣故事。