第一章：DNS和BIND9简介

互联网域名系统（DNS）由以下部分组成：

• 以分层方式指定互联网中实体名称的语法，
• 用于授权姓名的规则，以及
• 实际将名称映射到互联网地址的系统实现。

DNS数据保存在一组分布式分层数据库中。

1.1. 文件范围

伯克利互联网域名（Berkeley Internet Name Domain —— BIND）软件为许多操作系统实现了域名服务器。本文档为系统管理员提供了有关安装和维护互联网系统联盟（Internet Systems Consortium —— ISC）BIND版本9软件包的基本信息。

本手册涵盖BIND版本9.20.4。

1.2. 本文件的组织

• Introduction to DNS and BIND 9

  介绍了基本的DNS和BIND概念。为那些不熟悉DNS的人提供了一些关于 The Domain Name System (DNS) 的教程材料。提供 DNS Security Overview ，以便BIND运营商为其运营环境实施适当的安全措施。

• Resource Requirements

  描述了BIND 9的硬件和环境要求，并列出了支持和不支持的平台。

• Configurations and Zone Files

  旨在为新用户提供快速入门指南。包含Authoritative Name Servers（包括primary 和 secondary）的示例文件，以及简单的Resolver（Caching Name Servers）和 Forwarding Resolver Configuration。Zone File 中包含了一些参考资料。

• Name Server Operations

  涵盖了基本的BIND 9软件和DNS操作，包括一些有用的工具、Unix信号和插件。

• Advanced Configurations

  基于 Configurations and Zone Files 的配置，添加了系统管理员可能需要的功能和特性。

• Security Configurations

  涵盖了BIND 9安全的大部分方面，包括文件权限、在“监狱”中运行BIND 9以及保护文件传输和动态更新。

• DNSSEC

  描述了DNS信息加密认证的理论和实践。DNSSEC Guide 是实施DNSSEC的实用指南。

• Configuration Reference

  对BIND 9的 named.conf 配置文件中使用的所有支持的块、语句和语法进行了详尽的描述。

• Troubleshooting

  提供了有关识别和解决BIND 9和DNS问题的信息。还提供了有关错误报告程序的信息。

• Building BIND 9

  对于用户需要标准Linux或Unix发行版中没有提供的特殊选项的情况，这是一个权威的指南。

Appendices 包含有用的参考信息，例如与BIND和域名系统相关的参考书目和历史信息，以及所有已发布工具的当前 man 页。

1.3. 本文档使用的约定

在本文档中，我们通常使用 fixed-width (固定宽度)文本来表示以下类型的信息：

• 路径名
• 文件名
• URLs
• 主机名
• 邮件列表名称
• 新术语或概念
• 文字用户输入
• 程序输出
• 关键字
• 变量

“引号” 、粗体 或 斜体 中的文本也用于强调或清晰。

1.4. 域名系统 (DNS)

这是对域名系统（Domain Name System —— DNS）的功能和组织的简要描述。它的目的是让用户熟悉所涉及的概念、使用的（通常令人困惑的）术语，以及所有部分如何组合在一起形成一个操作系统。

所有网络系统都使用IPv4和IPv6等网络地址运行。绝大多数人发现使用名称比使用看似无穷无尽的网络地址数字更容易。最早的ARPANET系统（互联网由此发展而来）使用 hosts 文件将名称映射到地址，该文件在发生更改时分发给所有实体。在操作上，一旦有100多个网络实体，这样的系统就会迅速变得不可持续，这导致了我们今天使用的域名系统的规范和实施。

1.4.1. DNS 基本知识

DNS命名系统被组织为由多个级别组成的树形结构，因此它自然地创建了一个分布式系统。树中的每个节点都有一个标签，该标签定义了 Authority (权威) 的 Domain (域) （其区域或地带）。树中最上面的节点是 Root Domain (根域) ；它委托给下一级的 Domains (域名)，这些域名通常被称为 Top-Level Domains（TLDs——顶级域名） 。它们又委托给Second-Level Domains （SLDs——二级域名），以此类推。顶级域名（TLDs）包括一组特殊的TLDs，称为 Country Code Top-Level Domains （ccTLDs —— 国家代码顶级域名），其中每个国家都被分配了一个来自ISO 3166的唯一两个字符的国家代码作为其域名。

注： 域名系统由ICANN控制(https://www.icann.org)（501c非营利实体）；他们目前的政策是，任何由三个或更多字符组成的新顶级域名都可以由任何商业赞助商团体提出，如果符合ICANN的标准，将被添加到顶级域名中。

委托和权限的概念沿着DNS树（DNS层次结构）向下流动，如图所示：

Delegation and Authority in the DNS Name Space

域是树中节点的标签。domain name 唯一标识DNS树中的任何节点，并通过将所有域标签（每个标签在其父区域或权限域内都是唯一的）与分隔每个组件的点组合起来，从左到右写入，直到根域。在上图中，以下是所有域名：

xxxxxxxxxx
example.com
b.com
ac.uk
us
org

根有一个唯一的标签“.”（点），当它被写为域名时，通常会省略它，但当它被写成 Fully Qualified Domain Name （FQDN——完全限定域名）时，点必须存在。比如：

xxxxxxxxxx
example.com     # domain name
example.com.    # FQDN

1.4.2. 权力和授权

每个域（node——节点）都已从其父域 delegated (委派)了权限。委托权限包括特定的责任，以确保其委托的每个域在其权限区域或域内都有一个唯一的名称或标签，并维护其委托域的 authoritative (权威)列表。职责还包括操作两个（或多个）名称服务器（可能与第三方签订合同）的操作要求，这些服务器将在 zone file 中包含其权限区域内所有域名标签的权威数据。同样，树结构确保DNS名称空间自然分布。

下图说明了DNS名称空间中每个级别和每个域都存在 Authoritative Name Servers (权威名称服务器)：

Authoritative Name Servers in the DNS Name Space

注： 域(domain)和区域(zone)之间的区别可能会让人感到困惑。实际上，这些术语在DNS中通常是同义词。然而，如果你喜欢有向图和树结构理论或类似的异国情调，那么一个区域可以被视为穿过任何节点（或域）的弧，域位于其顶点。因此，该区域包含域下方的所有名称空间。然而，这可能会导致子区域的概念，而这些子区域确实在原始DNS规范中定义过。值得庆幸的是，“subzone ”一词已经在时间的迷雾中消失了。

1.4.3. 根服务器

root servers (根服务器)是DNS权威基础设施的关键部分。有13个根服务器（ a.root-servers.net 到 m.root-servers.net ）。数字13在历史上是基于可以打包到512字节UDP消息中的最大名称和IPv4数据量，而不是对某些文化认为不吉利的数字的反常亲和力。512字节的UDP数据限制不再是限制因素，所有根服务器现在都支持IPv4和IPv6。此外，几乎所有的根服务器都使用 anycast (任播)，现在有300多个根服务器实例在全球范围内提供服务（更多信息请参阅https://www.root-servers.org). 根服务器是DNS中所有名称解析的起点。

1.4.4. 名称解析

到目前为止，所有的重点都放在DNS如何存储其权威域（区域）数据上。终端用户系统使用名称（电子邮件地址或网址），需要访问此权威数据以获取IP地址，并使用该地址联系所需的网络资源，如web、FTP或邮件服务器。将域名转换为结果（通常是IP地址，但也可能获得其他类型的数据）的过程通常称为 name resolution (名称解析)，由 resolvers (解析器，也称为 caching name servers —— 缓存名称服务器和许多其他术语)处理。下图显示了典型的名称解析过程：

Authoritative Name Servers and Name Resolution

终端用户应用程序，如浏览器①，在需要解析 www.example.com 等名称时，会对称为stub resolver ②的最小函数解析实体进行内部系统调用。stub resolver（使用存储的IP地址）联系解析器（缓存名称服务器或全方位服务解析器）③，解析器进而联系所有必要的权威名称服务器（④、⑤和⑥），以提供答案，然后返回给用户（②、①）。为了提高性能，所有解析器（包括大多数存根解析器）都会缓存（存储）其结果，以便从解析器的缓存中获取对相同数据的后续请求，从而消除了重复名称解析过程和使用耗时资源的需要。存根解析器、解析器和权威名称服务器之间的所有通信都使用DNS协议的查询和响应消息对。

1.4.5. DNS协议和查询

DNS queries 在保留端口53上使用UDP协议（但TCP和TLS都可以在网络的某些部分使用）。

下图显示了以DNS查询和响应表示的名称解析过程：

Resolvers and Queries

stub解析器向解析器发送 recursive query (递归查询)消息（在查询的QUESTION部分包含所需的域名）②。递归查询只是请求解析器找到完整的答案。stub解析器只发送递归查询，并且始终需要解析器的服务。对递归查询的响应可以是：

1. 查询响应的 ANSWER 部分中对用户的 QUESTION 的回答。
2. 错误（例如 NXDOMAIN-名称不存在）。

解析器在收到用户的递归查询后，如果 ANSWER 在其缓存中，则立即响应，或者访问DNS层次结构以获取答案。解析器总是从根服务器开始，并发送 iterative query （迭代查询，4、5和6）。对迭代查询的响应可以是：

1. 查询响应的 ANSWER 部分中解析器的 QUESTION 的答案。
2. referral（转介，由空的 ANSWER 部分表示，但数据在权限部分，通常IP地址在响应的附加部分）。
3. 错误（例如 NXDOMAIN-名称不存在）。

如果响应是答案或错误，则会立即将其返回给用户（并缓存以供将来使用）。如果响应是引用，解析器需要采取额外的操作来响应用户的递归查询。

本质上，转介表示被查询的服务器不知道答案（响应的 ANSWER 部分为空），但它将解析器转介到它在查询的 QUESTION 部分提供的域名中知道的权威名称服务器（在响应的AUTHORITY部分）。因此，如果问题是针对域名 www.example.com ，则向其发送迭代查询的根服务器会在AUTHORITY部分添加.com权威名称服务器的列表。解析器从AUTHORITY部分选择一个服务器，并向其发送迭代查询。同样，.com权威名称服务器发送一个包含 example.com 权威名称服务器列表的引用。此过程在DNS层次结构中继续，直到收到应答或错误，此时用户的原始递归查询将收到响应。

注： DNS层次结构总是从根服务器开始访问，然后向下访问；DNS层次结构中没有“向上”的概念。显然，如果解析器已经缓存了.com权威名称服务器的列表，并且用户的递归查询QUESTION包含以.com结尾的域名，则可以省略对根服务器的访问。然而，这只是缓存的一个工件（在这种情况下是一个性能优势），并没有改变DNS层次结构中自上而下访问的概念。

永不满足的好奇心可能会发现阅读 RFC 1034 和 RFC 1035 是获取更多信息的有用起点。

1.4.6. DNS 和 BIND 9

BIND 9是DNS协议的完整实现。BIND 9可以（使用其 named.conf 文件）配置为权威名称服务器、解析器，以及在支持的主机上配置为存根解析器。虽然大型运营商通常将DNS服务器专用于每个系统的单个功能，但较小的运营商会发现BIND 9的灵活配置功能支持多种功能，例如单个DNS服务器同时充当权威名称服务器和解析器。

提供了基本 authoritative name servers 和 resolvers and forwarding resolvers 的示例配置，以及 advanced configurations 和 secure configurations 。

1.5. DNS 安全概述

DNS是一种通信协议。所有通信协议都可能容易受到颠覆(subversion)和窃听(eavesdropping)。对于用户来说，审计他们在操作环境中面临的各种威胁并实施适当的解决方案非常重要。BIND 9是DNS协议的具体实现，提供了一套广泛的安全功能。本节的目的是帮助用户从可用的安全功能范围中选择其特定用户环境所需的功能。

下面显示了一个通用的DNS网络，后面是文本描述。一般来说，从图的左侧走得越远，实现就越复杂。

注： 从历史上看，DNS数据被视为公共数据，安全主要涉及确保DNS数据的完整性。DNS数据隐私越来越被视为整体安全的一个重要方面，特别是DNS over TLS。

BIND 9 Security Overview

以下注释涉及上图中的编号元素：

1.可以使用各种系统管理技术和方法来保护BIND 9的本地环境，包括文件权限(file permissions)、在jail中运行BIND 9以及使用访问控制列表(Access Control Lists)。

2.远程名称守护进程控制（remote name daemon control —— rndc）程序允许系统管理员控制名称服务器的操作。大多数BIND 9包或端口都预先配置了本地（环回地址）安全配置。如果从远程主机调用 rndc ，则需要进一步配置。 nsupdate 工具使用动态DNS（Dynamic DNS —— DDNS）功能，允许用户动态更改区域文件的内容。nsupdate 访问和安全性可以使用 named.conf 语句或使用TSIG或SIG（0）加密方法进行控制。显然，如果用于 rndc 或DDNS的远程主机位于完全由用户控制的网络内，则安全威胁可能被视为不存在。因此，任何实施要求都取决于站点的安全策略。

3.通过公共网络从 primary 权威名称服务器向一个或多个 secondary 权威名称服务器进行区域转移存在风险。可以使用 named.conf 语句、TSIG加密方法或TLS来保护区域传输。显然，如果二级权威名称服务器都位于完全由用户控制的网络内，则安全威胁可能被视为不存在。任何实施要求再次取决于站点的安全策略。

4.如果权威名称服务器（primary 或 secondary）的运营商希望确保对用户发起的关于其负责的区域的查询的DNS响应只能来自其服务器，用户收到的数据与发送的数据相同，并且不存在的名称是真实的，那么DNSSEC是唯一的解决方案。DNSSEC要求对权威名称服务器和访问这些服务器的任何解析器进行配置和操作更改。

5.典型的互联网连接终端用户设备（个人电脑、笔记本电脑，甚至手机）要么有一个存根解析器，要么通过DNS代理运行。存根解析器需要区域或全方位服务解析器的服务来完全回答用户查询。大多数PC和笔记本电脑上的Stub解析器通常具有缓存功能以提高性能。目前还没有实现DNSSEC的标准存根解析器或代理DNS工具。BIND 9可以被配置为在支持的Linux或Unix平台上提供这种能力。DNS over TLS可以被配置为验证存根解析器和区域（或全服务）解析器之间的数据完整性。但是，除非解析器和权威名称服务器实现DNSSEC，否则无法保证端到端的完整性（从权威名称服务器到存根解析器）。