6. Advanced Configurations 6.高级配置

转载来源：https://bind9.readthedocs.io/en/latest/chapter6.html

6.1. Dynamic Update 6.1.动态更新

Dynamic update is a method for adding, replacing, or deleting records in a primary server by sending it a special form of DNS messages. The format and meaning of these messages is specified in RFC 2136. 动态更新是一种通过向主服务器发送特殊形式的 DNS 消息来添加、替换或删除记录的方法。这些消息的格式和含义在 RFC 2136 中指定。

Dynamic update is enabled by including an allow-update or an update-policy clause in the zone statement. 通过在 zone 语句中包含 allow-update 或 update-policy 子句来启用动态更新。

If the zone’s update-policy is set to local, updates to the zone are permitted for the key local-ddns, which is generated by named at startup. See Dynamic Update Policies for more details. 如果区域的 update-policy 设置为 local ，则允许更新区域的密钥 local-ddns ，它由 named 在启动时生成。有关详细信息，请参阅动态更新策略。

Dynamic updates using Kerberos-signed requests can be made using the TKEY/GSS protocol, either by setting the tkey-gssapi-keytab option or by setting both the tkey-gssapi-credential and tkey-domain options. Once enabled, Kerberos-signed requests are matched against the update policies for the zone, using the Kerberos principal as the signer for the request. 可以使用 TKEY/GSS 协议进行使用 Kerberos 签名请求的动态更新，方法是设置 tkey-gssapi-keytab 选项或同时设置 tkey-gssapi-credential 和 tkey-domain 选项。一旦启用，Kerberos 签名的请求将与区域的更新策略匹配，使用 Kerberos 主体作为请求的签名者。

Updating of secure zones (zones using DNSSEC) follows RFC 3007: RRSIG, NSEC, and NSEC3 records affected by updates are automatically regenerated by the server using an online zone key. Update authorization is based on transaction signatures and an explicit server policy. 安全区域（使用 DNSSEC 的区域）的更新遵循 RFC 3007：服务器使用在线区域密钥自动重新生成受更新影响的 RRSIG、NSEC 和 NSEC3 记录。更新授权基于事务签名和明确的服务器策略。

6.1.1. The Journal File 6.1.1.日志文件 

All changes made to a zone using dynamic update are stored in the zone’s journal file. This file is automatically created by the server when the first dynamic update takes place. The name of the journal file is formed by appending the extension .jnl to the name of the corresponding zone file unless specifically overridden. The journal file is in a binary format and should not be edited manually. 使用动态更新对区域所做的所有更改都存储在区域的日志文件中。当第一次动态更新发生时，该文件由服务器自动创建。除非特别覆盖，否则日志文件的名称是通过将扩展名 .jnl 附加到相应区域文件的名称而形成的。日志文件是二进制格式，不应手动编辑。

The server also occasionally writes (“dumps”) the complete contents of the updated zone to its zone file. This is not done immediately after each dynamic update because that would be too slow when a large zone is updated frequently. 服务器偶尔也会将更新区域的完整内容写入（“转储”）到其区域文件中。这不会在每次动态更新后立即完成，因为在频繁更新大区域时这样做会太慢。 Instead, the dump is delayed by up to 15 minutes, allowing additional updates to take place. During the dump process, transient files are created with the extensions .jnw and .jbk; under ordinary circumstances, these are removed when the dump is complete, and can be safely ignored. 相反，转储最多会延迟 15 分钟，从而允许进行其他更新。在转储过程中，会创建扩展名为 .jnw 和 .jbk 的临时文件；在一般情况下，这些在转储完成时被删除，可以安全地忽略。

When a server is restarted after a shutdown or crash, it replays the journal file to incorporate into the zone any updates that took place after the last zone dump. 当服务器在关闭或崩溃后重新启动时，它会重播日志文件以将上次区域转储后发生的任何更新合并到区域中。

Changes that result from incoming incremental zone transfers are also journaled in a similar way. 传入的增量区域传输导致的更改也以类似的方式记录在日志中。

The zone files of dynamic zones cannot normally be edited by hand because they are not guaranteed to contain the most recent dynamic changes; those are only in the journal file. The only way to ensure that the zone file of a dynamic zone is up-to-date is to run rndc stop. 动态区域的区域文件通常不能手动编辑，因为它们不能保证包含最新的动态更改；那些只在日志文件中。确保动态区域的区域文件是最新的唯一方法是运行 rndc stop 。

To make changes to a dynamic zone manually, follow these steps: first, disable dynamic updates to the zone using rndc freeze zone. This updates the zone file with the changes stored in its .jnl file. Then, edit the zone file. Finally, run rndc thaw zone to reload the changed zone and re-enable dynamic updates. 要手动更改动态区域，请执行以下步骤：首先，使用 rndc freeze zone 禁用对区域的动态更新。这将使用存储在其 .jnl 文件中的更改更新区域文件。然后，编辑区域文件。最后，运行 rndc thaw zone 重新加载更改的区域并重新启用动态更新。

rndc sync zone updates the zone file with changes from the journal file without stopping dynamic updates; this may be useful for viewing the current zone state. To remove the .jnl file after updating the zone file, use rndc sync -clean. rndc sync zone 在不停止动态更新的情况下使用日志文件的更改更新区域文件；这对于查看当前区域状态可能很有用。要在更新区域文件后删除 .jnl 文件，请使用 rndc sync -clean 。

6.2. NOTIFY

DNS NOTIFY is a mechanism that allows primary servers to notify their secondary servers of changes to a zone’s data. DNS NOTIFY 是一种允许主服务器将区域数据更改通知其辅助服务器的机制。 In response to a NOTIFY message from a primary server, the secondary checks to see that its version of the zone is the current version and, if not, initiates a zone transfer. 为响应来自主服务器的 NOTIFY 消息，辅助服务器检查其区域版本是否为当前版本，如果不是，则启动区域传输。

For more information about DNS NOTIFY, see the description of the notify and :namedconf:refalso-notify statements. The NOTIFY protocol is specified in RFC 1996. 有关 DNS NOTIFY 的更多信息，请参阅 notify 和 :namedconf:refalso-notify 语句的说明。 NOTIFY 协议在 RFC 1996 中指定。

Note

As a secondary zone can also be a primary to other secondaries, named, by default, sends NOTIFY messages for every zone it loads. 由于辅助区域也可以是其他辅助区域的主要区域， named 默认情况下会为其加载的每个区域发送 NOTIFY 消息。

6.3. Incremental Zone Transfers (IXFR) 6.3.增量区域传输 (IXFR) 

The incremental zone transfer (IXFR) protocol is a way for secondary servers to transfer only changed data, instead of having to transfer an entire zone. The IXFR protocol is specified in RFC 1995. 增量区域传输 (IXFR) 协议是辅助服务器仅传输更改的数据而不必传输整个区域的一种方式。 IXFR 协议在 RFC 1995 中指定。

When acting as a primary server, BIND 9 supports IXFR for those zones where the necessary change history information is available. These include primary zones maintained by dynamic update and secondary zones whose data was obtained by IXFR. 当作为主服务器时，BIND 9 支持 IXFR 用于那些必要的更改历史信息可用的区域。这些包括由动态更新维护的主要区域和其数据由 IXFR 获取的次要区域。 For manually maintained primary zones, and for secondary zones obtained by performing a full zone transfer (AXFR), IXFR is supported only if the option ixfr-from-differences is set to yes. 对于手动维护的主要区域，以及通过执行完整区域传输 (AXFR) 获得的次要区域，仅当选项 ixfr-from-differences 设置为 yes 时才支持 IXFR。

When acting as a secondary server, BIND 9 attempts to use IXFR unless it is explicitly disabled. For more information about disabling IXFR, see the description of the request-ixfr clause of the server statement. 作为辅助服务器时，BIND 9 会尝试使用 IXFR，除非它被明确禁用。有关禁用 IXFR 的详细信息，请参阅 server 语句的 request-ixfr 子句的说明。

When a secondary server receives a zone via AXFR, it creates a new copy of the zone database and then swaps it into place; during the loading process, queries continue to be served from the old database with no interference. 当辅助服务器通过 AXFR 接收到区域时，它会创建区域数据库的新副本，然后将其交换到位；在加载过程中，查询继续从旧数据库提供服务而不受干扰。 When receiving a zone via IXFR, however, changes are applied to the running zone, which may degrade query performance during the transfer. 但是，当通过 IXFR 接收区域时，更改将应用​​于正在运行的区域，这可能会降低传输期间的查询性能。 If a server receiving an IXFR request determines that the response size would be similar in size to an AXFR response, it may wish to send AXFR instead. The threshold at which this determination is made can be configured using the max-ixfr-ratio option. 如果接收 IXFR 请求的服务器确定响应大小与 AXFR 响应的大小相似，它可能希望改为发送 AXFR。可以使用 max-ixfr-ratio 选项配置进行此确定的阈值。

6.4. Split DNS 6.4.拆分 DNS 

Setting up different views of the DNS space to internal and external resolvers is usually referred to as a split DNS setup. There are several reasons an organization might want to set up its DNS this way. 为内部和外部解析器设置不同的 DNS 空间视图通常称为拆分 DNS 设置。组织可能希望以这种方式设置其 DNS 的原因有多种。

One common reason to use split DNS is to hide “internal” DNS information from “external” clients on the Internet. There is some debate as to whether this is actually useful. Internal DNS information leaks out in many ways (via email headers, for example) and most savvy “attackers” can find the information they need using other means. 使用拆分 DNS 的一个常见原因是向 Internet 上的“外部”客户端隐藏“内部”DNS 信息。关于这是否真的有用存在一些争论。内部 DNS 信息以多种方式泄露（例如，通过电子邮件标头），大多数精明的“攻击者”可以使用其他方式找到他们需要的信息。 However, since listing addresses of internal servers that external clients cannot possibly reach can result in connection delays and other annoyances, an organization may choose to use split DNS to present a consistent view of itself to the outside world. 但是，由于列出外部客户端无法访问的内部服务器地址会导致连接延迟和其他烦恼，因此组织可能会选择使用拆分 DNS 来向外界呈现一致的自身视图。

Another common reason for setting up a split DNS system is to allow internal networks that are behind filters or in RFC 1918 space (reserved IP space, as documented in RFC 1918) to resolve DNS on the Internet. Split DNS can also be used to allow mail from outside back into the internal network. 设置拆分 DNS 系统的另一个常见原因是允许位于过滤器后面或 RFC 1918 空间（保留的 IP 空间，如 RFC 1918 中所述）的内部网络解析 Internet 上的 DNS。拆分 DNS 也可用于允许邮件从外部返回到内部网络。

6.4.1. Example Split DNS Setup 6.4.1.拆分 DNS 设置示例 

Let’s say a company named Example, Inc. (example.com) has several corporate sites that have an internal network with reserved Internet Protocol (IP) space and an external demilitarized zone (DMZ), or “outside” section of a network, that is available to the public. 假设一家名为 Example, Inc. ( example.com ) 的公司有多个公司站点，这些站点具有带保留 Internet 协议 (IP) 空间的内部网络和外部非军事区 (DMZ) 或网络的“外部”部分，即对公众开放。

Example, Inc. wants its internal clients to be able to resolve external hostnames and to exchange mail with people on the outside. Example, Inc. 希望其内部客户能够解析外部主机名并与外部人员交换邮件。 The company also wants its internal resolvers to have access to certain internal-only zones that are not available at all outside of the internal network. 该公司还希望其内部解析器能够访问某些仅供内部使用的区域，这些区域在内部网络之外根本不可用。

To accomplish this, the company sets up two sets of name servers. One set is on the inside network (in the reserved IP space) and the other set is on bastion hosts, which are “proxy” hosts in the DMZ that can talk to both sides of its network. 为此，该公司设置了两套名称服务器。一组在内部网络上（在保留的 IP 空间中），另一组在堡垒主机上，堡垒主机是 DMZ 中的“代理”主机，可以与其网络的两端对话。

The internal servers are configured to forward all queries, except queries for site1.internal, site2.internal, site1.example.com, and site2.example.com, to the servers in the DMZ. These internal servers have complete sets of information for site1.example.com, site2.example.com, site1.internal, and site2.internal. 内部服务器配置为将所有查询（ site1.internal 、 site2.internal 、 site1.example.com 和 site2.example.com 的查询除外）转发到 DMZ 中的服务器。这些内部服务器拥有 site1.example.com 、 site2.example.com 、 site1.internal 和 site2.internal 的完整信息集。

To protect the site1.internal and site2.internal domains, the internal name servers must be configured to disallow all queries to these domains from any external hosts, including the bastion hosts. 为了保护 site1.internal 和 site2.internal 域，必须将内部名称服务器配置为禁止来自任何外部主机（包括堡垒主机）对这些域的所有查询。

The external servers, which are on the bastion hosts, are configured to serve the “public” version of the site1.example.com and site2.example.com zones. This could include things such as the host records for public servers (www.example.com and ftp.example.com) and mail exchange (MX) records (a.mx.example.com and b.mx.example.com). 堡垒主机上的外部服务器被配置为服务 site1.example.com 和 site2.example.com 区域的“公共”版本。这可能包括诸如公共服务器的主机记录（ www.example.com 和 ftp.example.com ）和邮件交换 (MX) 记录（ a.mx.example.com 和 b.mx.example.com ）之类的内容。

In addition, the public site1.example.com and site2.example.com zones should have special MX records that contain wildcard (*) records pointing to the bastion hosts. This is needed because external mail servers have no other way of determining how to deliver mail to those internal hosts. 此外，公共 site1.example.com 和 site2.example.com 区域应该有特殊的 MX 记录，其中包含指向堡垒主机的通配符 ( * ) 记录。这是必需的，因为外部邮件服务器没有其他方法来确定如何将邮件传递到这些内部主机。 With the wildcard records, the mail is delivered to the bastion host, which can then forward it on to internal hosts. 通过通配符记录，邮件被传送到堡垒主机，然后堡垒主机可以将其转发到内部主机。

Here’s an example of a wildcard MX record: 以下是通配符 MX 记录的示例：

*   IN MX 10 external1.example.com.

Now that they accept mail on behalf of anything in the internal network, the bastion hosts need to know how to deliver mail to internal hosts. The resolvers on the bastion hosts need to be configured to point to the internal name servers for DNS resolution. 既然它们代表内部网络中的任何事物接收邮件，堡垒主机就需要知道如何将邮件传递到内部主机。堡垒主机上的解析器需要配置为指向内部名称服务器以进行 DNS 解析。

Queries for internal hostnames are answered by the internal servers, and queries for external hostnames are forwarded back out to the DNS servers on the bastion hosts. 对内部主机名的查询由内部服务器回答，对外部主机名的查询转发回堡垒主机上的 DNS 服务器。

For all of this to work properly, internal clients need to be configured to query only the internal name servers for DNS queries. This could also be enforced via selective filtering on the network. 为了使所有这些正常工作，内部客户端需要配置为仅查询内部名称服务器以进行 DNS 查询。这也可以通过网络上的选择性过滤来实施。

If everything has been set properly, Example, Inc.’s internal clients are now able to: 如果一切设置正确，Example, Inc. 的内部客户现在能够：

• Look up any hostnames in the site1.example.com and site2.example.com zones. 查找 site1.example.com 和 site2.example.com 区域中的所有主机名。
• Look up any hostnames in the site1.internal and site2.internal domains. 在 site1.internal 和 site2.internal 域中查找任何主机名。
• Look up any hostnames on the Internet. 在 Internet 上查找任何主机名。
• Exchange mail with both internal and external users. 与内部和外部用户交换邮件。

Hosts on the Internet are able to: 互联网上的主机能够：

• Look up any hostnames in the site1.example.com and site2.example.com zones. 查找 site1.example.com 和 site2.example.com 区域中的所有主机名。
• Exchange mail with anyone in the site1.example.com and site2.example.com zones. 与 site1.example.com 和 site2.example.com 区域中的任何人交换邮件。

Here is an example configuration for the setup just described above. Note that this is only configuration information; for information on how to configure the zone files, see Configurations and Zone Files. 这是上述设置的示例配置。请注意，这只是配置信息；有关如何配置区域文件的信息，请参阅配置和区域文件。

Internal DNS server config: 内部 DNS 服务器配置：

acl internals { 172.16.72.0/24; 192.168.1.0/24; };

acl externals { bastion-ips-go-here; };

options {
    ...
    ...
    forward only;
    // forward to external servers
    forwarders {
    bastion-ips-go-here;
    };
    // sample allow-transfer (no one)
    allow-transfer { none; };
    // restrict query access
    allow-query { internals; externals; };
    // restrict recursion
    allow-recursion { internals; };
    ...
    ...
};

// sample primary zone
zone "site1.example.com" {
  type primary;
  file "m/site1.example.com";
  // do normal iterative resolution (do not forward)
  forwarders { };
  allow-query { internals; externals; };
  allow-transfer { internals; };
};

// sample secondary zone
zone "site2.example.com" {
  type secondary;
  file "s/site2.example.com";
  primaries { 172.16.72.3; };
  forwarders { };
  allow-query { internals; externals; };
  allow-transfer { internals; };
};

zone "site1.internal" {
  type primary;
  file "m/site1.internal";
  forwarders { };
  allow-query { internals; };
  allow-transfer { internals; }
};

zone "site2.internal" {
  type secondary;
  file "s/site2.internal";
  primaries { 172.16.72.3; };
  forwarders { };
  allow-query { internals };
  allow-transfer { internals; }
};

External (bastion host) DNS server configuration: 外部（堡垒机）DNS服务器配置：

acl internals { 172.16.72.0/24; 192.168.1.0/24; };

acl externals { bastion-ips-go-here; };

options {
  ...
  ...
  // sample allow-transfer (no one)
  allow-transfer { none; };
  // default query access
  allow-query { any; };
  // restrict cache access
  allow-query-cache { internals; externals; };
  // restrict recursion
  allow-recursion { internals; externals; };
  ...
  ...
};

// sample secondary zone
zone "site1.example.com" {
  type primary;
  file "m/site1.foo.com";
  allow-transfer { internals; externals; };
};

zone "site2.example.com" {
  type secondary;
  file "s/site2.foo.com";
  primaries { another_bastion_host_maybe; };
  allow-transfer { internals; externals; }
};

In the resolv.conf (or equivalent) on the bastion host(s): 在堡垒主机上的 resolv.conf （或等效项）中：

search ...
nameserver 172.16.72.2
nameserver 172.16.72.3
nameserver 172.16.72.4

6.5. IPv6 Support in BIND 9 6.5. BIND 9 中的 IPv6 支持 

BIND 9 fully supports all currently defined forms of IPv6 name-to-address and address-to-name lookups. It also uses IPv6 addresses to make queries when running on an IPv6-capable system. BIND 9 完全支持所有当前定义的 IPv6 名称到地址和地址到名称查找形式。当在支持 IPv6 的系统上运行时，它还使用 IPv6 地址进行查询。

For forward lookups, BIND 9 supports only AAAA records. RFC 3363 deprecated the use of A6 records, and client-side support for A6 records was accordingly removed from BIND 9. However, authoritative BIND 9 name servers still load zone files containing A6 records correctly, answer queries for A6 records, and accept zone transfer for a zone containing A6 records. 对于正向查找，BIND 9 仅支持 AAAA 记录。 RFC 3363 反对使用 A6 记录，因此从 BIND 9 中删除了对 A6 记录的客户端支持。但是，权威的 BIND 9 名称服务器仍然正确加载包含 A6 记录的区域文件，回答 A6 记录的查询，并接受区域传输对于包含 A6 记录的区域。

For IPv6 reverse lookups, BIND 9 supports the traditional “nibble” format used in the ip6.arpa domain, as well as the older, deprecated ip6.int domain. Older versions of BIND 9 supported the “binary label” (also known as “bitstring”) format, but support of binary labels has been completely removed per RFC 3363. Many applications in BIND 9 do not understand the binary label format at all anymore, and return an error if one is given. In particular, an authoritative BIND 9 name server will not load a zone file containing binary labels. 对于 IPv6 反向查找，BIND 9 支持 ip6.arpa 域中使用的传统“半字节”格式，以及旧的、已弃用的 ip6.int 域。旧版本的 BIND 9 支持“二进制标签”（也称为“位串”）格式，但根据 RFC 3363 已完全删除对二进制标签的支持。BIND 9 中的许多应用程序根本不再理解二进制标签格式，如果给出一个错误，则返回错误。特别是，权威的 BIND 9 名称服务器不会加载包含二进制标签的区域文件。

6.5.1. Address Lookups Using AAAA Records 6.5.1.使用 AAAA 记录查找地址 

The IPv6 AAAA record is a parallel to the IPv4 A record, and, unlike the deprecated A6 record, specifies the entire IPv6 address in a single record. For example: IPv6 AAAA 记录与 IPv4 A 记录平行，并且与已弃用的 A6 记录不同，它在单个记录中指定了整个 IPv6 地址。例如：

$ORIGIN example.com.
host            3600    IN      AAAA    2001:db8::1

Use of IPv4-in-IPv6 mapped addresses is not recommended. If a host has an IPv4 address, use an A record, not a AAAA, with ::ffff:192.168.42.1 as the address. 不建议使用 IPv4-in-IPv6 映射地址。如果主机有 IPv4 地址，请使用 A 记录，而不是 AAAA，并将 ::ffff:192.168.42.1 作为地址。

6.5.2. Address-to-Name Lookups Using Nibble Format 6.5.2.使用半字节格式的地址到名称查找 

When looking up an address in nibble format, the address components are simply reversed, just as in IPv4, and ip6.arpa. is appended to the resulting name. For example, the following commands produce a reverse name lookup for a host with address 2001:db8::1: 查找半字节格式的地址时，地址部分只是简单地反转，就像在 IPv4 中一样， ip6.arpa. 附加到结果名称。例如，以下命令为地址为 2001:db8::1 的主机生成反向名称查找：

$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0  14400   IN    PTR    (
                    host.example.com. )

6.6. Dynamically Loadable Zones (DLZ) 6.6.动态加载区 (DLZ) 

Dynamically Loadable Zones (DLZ) are an extension to BIND 9 that allows zone data to be retrieved directly from an external database. There is no required format or schema. 动态可加载区域 (DLZ) 是 BIND 9 的扩展，它允许直接从外部数据库检索区域数据。没有必需的格式或架构。 DLZ modules exist for several different database backends, including MySQL and LDAP, and can be written for any other. DLZ 模块存在于几种不同的数据库后端，包括 MySQL 和 LDAP，并且可以为任何其他数据库编写。

The DLZ module provides data to named in text format, which is then converted to DNS wire format by named. This conversion, and the lack of any internal caching, places significant limits on the query performance of DLZ modules. Consequently, DLZ is not recommended for use on high-volume servers. DLZ 模块以文本格式向 named 提供数据，然后由 named 将其转换为 DNS 有线格式。这种转换以及缺少任何内部缓存对 DLZ 模块的查询性能造成了很大限制。因此，不建议在大容量服务器上使用 DLZ。 However, it can be used in a hidden primary configuration, with secondaries retrieving zone updates via AXFR. Note, however, that DLZ has no built-in support for DNS notify; secondary servers are not automatically informed of changes to the zones in the database. 但是，它可以用于隐藏的主要配置，次要配置通过 AXFR 检索区域更新。但是请注意，DLZ 没有对 DNS 通知的内置支持；辅助服务器不会自动通知数据库中区域的更改。

6.6.1. Configuring DLZ 6.6.1.配置 DLZ 

• dlz dlz 

  Grammar zone (primary, redirect, secondary): dlz <string>; 语法区（主要、重定向、次要）： dlz <string>;Grammar topmost, view: 语法最顶层，查看：dlz <string> { database <string>; search <boolean>; }; // may occur multiple timesBlocks: topmost, view, zone (primary, redirect, secondary) 块：最顶层、视图、区域（主要、重定向、次要）Tags: zoneConfigures a Dynamically Loadable Zone (DLZ) database in named.conf. 在 named.conf 中配置动态可加载区域 (DLZ) 数据库。

A DLZ database is configured with a dlz statement in named.conf: DLZ 数据库在 named.conf 中配置了 dlz 语句：

dlz example {
database "dlopen driver.so args";
search yes;
};

This specifies a DLZ module to search when answering queries; the module is implemented in driver.so and is loaded at runtime by the dlopen DLZ driver. Multiple dlz statements can be specified. 这指定了在回答查询时要搜索的 DLZ 模块；该模块在 driver.so 中实现，并在运行时由 dlopen DLZ 驱动程序加载。可以指定多个 dlz 语句。

• search 搜索

  Grammar: search <boolean>;Blocks: dlz, view.dlz 块：dlz，view.dlzTags: querySpecifies whether a Dynamically Loadable Zone (DLZ) module is queried for an answer to a query name. 指定是否查询动态可加载区域 (DLZ) 模块以获得查询名称的答案。

When answering a query, all DLZ modules with search set to yes are queried to see whether they contain an answer for the query name. The best available answer is returned to the client. 回答查询时，将查询所有 search 设置为 yes 的 DLZ 模块，以查看它们是否包含查询名称的答案。最佳可用答案返回给客户端。

The search option in the above example can be omitted, because yes is the default value. 上例中的 search 选项可以省略，因为 yes 是默认值。

If search is set to no, this DLZ module is not searched for the best match when a query is received. Instead, zones in this DLZ must be separately specified in a zone statement. 如果 search 设置为 no ，则在收到查询时不会搜索此 DLZ 模块以寻找最佳匹配。相反，此 DLZ 中的区域必须在区域语句中单独指定。 This allows users to configure a zone normally using standard zone-option semantics, but specify a different database backend for storage of the zone’s data. For example, to implement NXDOMAIN redirection using a DLZ module for backend storage of redirection rules: 这允许用户通常使用标准区域选项语义配置区域，但指定不同的数据库后端来存储区域数据。例如，要使用用于重定向规则后端存储的 DLZ 模块来实现 NXDOMAIN 重定向：

dlz other {
       database "dlopen driver.so args";
       search no;
};

zone "." {
       type redirect;
       dlz other;
};

6.6.2. Sample DLZ Module 6.6.2.示例 DLZ 模块 

For guidance in the implementation of DLZ modules, the directory contrib/dlz/example contains a basic dynamically linkable DLZ module – i.e., one which can be loaded at runtime by the “dlopen” DLZ driver. The example sets up a single zone, whose name is passed to the module as an argument in the dlz statement: 为了指导 DLZ 模块的实现，目录 contrib/dlz/example 包含一个基本的动态可链接 DLZ 模块——即，一个可以在运行时由“dlopen”DLZ 驱动程序加载的模块。该示例设置了一个区域，其名称作为 dlz 语句中的参数传递给模块：

dlz other {
       database "dlopen driver.so example.nil";
};

In the above example, the module is configured to create a zone “example.nil”, which can answer queries and AXFR requests and accept DDNS updates. At runtime, prior to any updates, the zone contains an SOA, NS, and a single A record at the apex: 在上面的例子中，模块被配置为创建一个区域“example.nil”，它可以回答查询和 AXFR 请求并接受 DDNS 更新。在运行时，在任何更新之前，该区域在顶点包含一个 SOA、NS 和一个 A 记录：

example.nil.  3600    IN      SOA     example.nil. hostmaster.example.nil. (
                          123 900 600 86400 3600
                      )
example.nil.  3600    IN      NS      example.nil.
example.nil.  1800    IN      A       10.53.0.1

The sample driver can retrieve information about the querying client and alter its response on the basis of this information. To demonstrate this feature, the example driver responds to queries for “source-addr.zonename>/TXT” with the source address of the query. 示例驱动程序可以检索有关查询客户端的信息，并根据此信息更改其响应。为了演示此功能，示例驱动程序使用查询的源地址响应“source-addr.zonename>/TXT”的查询。 Note, however, that this record will not be included in AXFR or ANY responses. Normally, this feature is used to alter responses in some other fashion, e.g., by providing different address records for a particular name depending on the network from which the query arrived. 但是请注意，此记录不会包含在 AXFR 或 ANY 响应中。通常，此功能用于以其他方式更改响应，例如，根据查询到达的网络为特定名称提供不同的地址记录。

Documentation of the DLZ module API can be found in contrib/dlz/example/README. This directory also contains the header file dlz_minimal.h, which defines the API and should be included by any dynamically linkable DLZ module. DLZ 模块 API 的文档可以在 contrib/dlz/example/README 中找到。该目录还包含头文件 dlz_minimal.h ，它定义了 API 并且应该被任何可动态链接的 DLZ 模块包含。

6.7. Dynamic Database (DynDB) 6.7.动态数据库 (DynDB) 

Dynamic Database, or DynDB, is an extension to BIND 9 which, like DLZ (see Dynamically Loadable Zones (DLZ)), allows zone data to be retrieved from an external database. Unlike DLZ, a DynDB module provides a full-featured BIND zone database interface. 动态数据库或 DynDB 是 BIND 9 的扩展，它与 DLZ（请参阅动态可加载区域 (DLZ)）一样，允许从外部数据库检索区域数据。与 DLZ 不同，DynDB 模块提供功能齐全的 BIND 区域数据库接口。 Where DLZ translates DNS queries into real-time database lookups, resulting in relatively poor query performance, and is unable to handle DNSSEC-signed data due to its limited API, a DynDB module can pre-load an in-memory database from the external data source, providing the same performance and functionality as zones served natively by BIND. DLZ 将 DNS 查询转化为实时数据库查询，导致查询性能相对较差，并且由于其 API 有限而无法处理 DNSSEC 签名的数据，DynDB 模块可以从外部数据预加载内存数据库源，提供与 BIND 本地服务的区域相同的性能和功能。

A DynDB module supporting LDAP has been created by Red Hat and is available from https://pagure.io/bind-dyndb-ldap. 支持 LDAP 的 DynDB 模块已由 Red Hat 创建，可从 https://pagure.io/bind-dyndb-ldap 获得。

A sample DynDB module for testing and developer guidance is included with the BIND source code, in the directory bin/tests/system/dyndb/driver. 用于测试和开发人员指导的示例 DynDB 模块包含在 BIND 源代码中，位于目录 bin/tests/system/dyndb/driver 中。

6.7.1. Configuring DynDB 6.7.1.配置 DynDB 

• dyndb 动态表

  Grammar: dyndb <string> <quoted_string> { <unspecified-text> }; // may occur multiple timesBlocks: topmost, view 块：最顶层，视图Tags: zoneConfigures a DynDB database in named.conf. 在 named.conf 中配置 DynDB 数据库。

A DynDB database is configured with a dyndb statement in named.conf: DynDB 数据库在 named.conf 中配置了 dyndb 语句：

dyndb example "driver.so" {
    parameters
};

The file driver.so is a DynDB module which implements the full DNS database API. Multiple dyndb statements can be specified, to load different drivers or multiple instances of the same driver. Zones provided by a DynDB module are added to the view’s zone table, and are treated as normal authoritative zones when BIND responds to queries. driver.so 文件是一个 DynDB 模块，它实现了完整的 DNS 数据库 API。可以指定多个 dyndb 语句，以加载不同的驱动程序或同一驱动程序的多个实例。 DynDB 模块提供的区域被添加到视图的区域表中，并在 BIND 响应查询时被视为正常的权威区域。 Zone configuration is handled internally by the DynDB module. 区域配置由 DynDB 模块在内部处理。

The parameters are passed as an opaque string to the DynDB module’s initialization routine. Configuration syntax differs depending on the driver. 参数作为不透明字符串传递给 DynDB 模块的初始化例程。配置语法因驱动程序而异。

6.7.2. Sample DynDB Module 6.7.2.示例 DynDB 模块 

For guidance in the implementation of DynDB modules, the directory bin/tests/system/dyndb/driver contains a basic DynDB module. The example sets up two zones, whose names are passed to the module as arguments in the dyndb statement: 为了指导 DynDB 模块的实现， bin/tests/system/dyndb/driver 目录包含一个基本的 DynDB 模块。该示例设置了两个区域，它们的名称作为 dyndb 语句中的参数传递给模块：

dyndb sample "sample.so" { example.nil. arpa. };

In the above example, the module is configured to create a zone, “example.nil”, which can answer queries and AXFR requests and accept DDNS updates. At runtime, prior to any updates, the zone contains an SOA, NS, and a single A record at the apex: 在上面的示例中，模块被配置为创建一个区域“example.nil”，它可以回答查询和 AXFR 请求并接受 DDNS 更新。在运行时，在任何更新之前，该区域在顶点包含一个 SOA、NS 和一个 A 记录：

example.nil.  86400    IN      SOA     example.nil. example.nil. (
                                              0 28800 7200 604800 86400
                                      )
example.nil.  86400    IN      NS      example.nil.
example.nil.  86400    IN      A       127.0.0.1

When the zone is updated dynamically, the DynDB module determines whether the updated RR is an address (i.e., type A or AAAA); if so, it automatically updates the corresponding PTR record in a reverse zone. 当区域动态更新时，DynDB 模块会判断更新的 RR 是否为地址（即类型 A 或 AAAA）；如果是，它会自动更新反向区域中相应的 PTR 记录。 Note that updates are not stored permanently; all updates are lost when the server is restarted. 请注意，更新不会永久存储；服务器重新启动时，所有更新都将丢失。

6.8. Catalog Zones 6.8.目录区 

A “catalog zone” is a special DNS zone that contains a list of other zones to be served, along with their configuration parameters. “目录区域”是一个特殊的 DNS 区域，其中包含要服务的其他区域列表及其配置参数。 Zones listed in a catalog zone are called “member zones.” When a catalog zone is loaded or transferred to a secondary server which supports this functionality, the secondary server creates the member zones automatically. 目录区域中列出的区域称为“成员区域”。当目录区域加载或传输到支持此功能的辅助服务器时，辅助服务器会自动创建成员区域。 When the catalog zone is updated (for example, to add or delete member zones, or change their configuration parameters), those changes are immediately put into effect. 更新目录区域时（例如，添加或删除成员区域，或更改其配置参数），这些更改会立即生效。 Because the catalog zone is a normal DNS zone, these configuration changes can be propagated using the standard AXFR/IXFR zone transfer mechanism. 因为目录区域是一个普通的 DNS 区域，所以可以使用标准的 AXFR/IXFR 区域传输机制传播这些配置更改。

Catalog zones’ format and behavior are specified as an Internet draft for interoperability among DNS implementations. The latest revision of the DNS catalog zones draft can be found here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ . 目录区域的格式和行为被指定为 DNS 实施之间互操作性的 Internet 草案。可在此处找到 DNS 目录区域草案的最新版本：https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/。

6.8.1. Principle of Operation 6.8.1.工作原理

Normally, if a zone is to be served by a secondary server, the named.conf file on the server must list the zone, or the zone must be added using rndc addzone. In environments with a large number of secondary servers, and/or where the zones being served are changing frequently, the overhead involved in maintaining consistent zone configuration on all the secondary servers can be significant. 通常，如果一个区域要由辅助服务器提供服务，服务器上的 named.conf 文件必须列出该区域，或者必须使用 rndc addzone 添加该区域。在具有大量辅助服务器和/或所服务的区域频繁更改的环境中，在所有辅助服务器上维护一致的区域配置所涉及的开销可能很大。

A catalog zone is a way to ease this administrative burden: it is a DNS zone that lists member zones that should be served by secondary servers. When a secondary server receives an update to the catalog zone, it adds, removes, or reconfigures member zones based on the data received. 目录区域是减轻这种管理负担的一种方式：它是一个 DNS 区域，列出了应由辅助服务器提供服务的成员区域。当辅助服务器收到目录区域的更新时，它会根据收到的数据添加、删除或重新配置成员区域。

To use a catalog zone, it must first be set up as a normal zone on both the primary and secondary servers that are configured to use it. It must also be added to a catalog-zones list in the options or view statement in named.conf. This is comparable to the way a policy zone is configured as a normal zone and also listed in a response-policy statement. 要使用目录区域，必须首先在配置为使用它的主服务器和辅助服务器上将其设置为普通区域。它还必须添加到 named.conf 中 options 或 view 语句中的 catalog-zones 列表。这类似于将策略区域配置为普通区域并在 response-policy 语句中列出的方式。

To use the catalog zone feature to serve a new member zone: 要使用目录区域功能为新成员区域提供服务：

• Set up the member zone to be served on the primary as normal. This can be done by editing named.conf or by running rndc addzone. 将成员区域设置为在主区域上照常提供服务。这可以通过编辑 named.conf 或运行 rndc addzone 来完成。
• Add an entry to the catalog zone for the new member zone. This can be done by editing the catalog zone’s zone file and running rndc reload, or by updating the zone using nsupdate. 将条目添加到新成员区域的目录区域。这可以通过编辑目录区域的区域文件并运行 rndc reload 或使用 nsupdate 更新区域来完成。

The change to the catalog zone is propagated from the primary to all secondaries using the normal AXFR/IXFR mechanism. 使用正常的 AXFR/IXFR 机制将对目录区域的更改从主节点传播到所有辅助节点。 When the secondary receives the update to the catalog zone, it detects the entry for the new member zone, creates an instance of that zone on the secondary server, and points that instance to the primaries specified in the catalog zone data. The newly created member zone is a normal secondary zone, so BIND immediately initiates a transfer of zone contents from the primary. Once complete, the secondary starts serving the member zone. 当辅助服务器接收到目录区域的更新时，它会检测新成员区域的条目，在辅助服务器上创建该区域的实例，并将该实例指向目录区域数据中指定的 primaries 。新创建的成员区域是一个普通的辅助区域，因此 BIND 会立即启动从主区域传输区域内容。完成后，辅助节点开始为成员区域提供服务。

Removing a member zone from a secondary server requires only deleting the member zone’s entry in the catalog zone; the change to the catalog zone is propagated to the secondary server using the normal AXFR/IXFR transfer mechanism. 从辅助服务器中删除成员区域只需要删除目录区域中成员区域的条目；使用正常的 AXFR/IXFR 传输机制将对目录区域的更改传播到辅助服务器。 The secondary server, on processing the update, notices that the member zone has been removed, stops serving the zone, and removes it from its list of configured zones. However, removing the member zone from the primary server must be done by editing the configuration file or running rndc delzone. 辅助服务器在处理更新时注意到成员区域已被删除，停止为该区域提供服务，并将其从其已配置区域列表中删除。但是，从主服务器中删除成员区域必须通过编辑配置文件或运行 rndc delzone 来完成。

6.8.2. Configuring Catalog Zones 6.8.2.配置目录区域 

• catalog-zones 目录区

  Grammar: catalog-zones { zone <string> [ default-primaries [ port <integer> ] [ source ( <ipv4_address> | * ) ] [ source-v6 ( <ipv6_address> | * ) ] { ( <remote-servers> | <ipv4_address> [ port <integer> ] | <ipv6_address> [ port <integer> ] ) [ key <string> ] [ tls <string> ]; ... } ] [ zone-directory <quoted_string> ] [ in-memory <boolean> ] [ min-update-interval <duration> ]; ... };Blocks: options, view 块：选项，视图Tags: zoneConfigures catalog zones in named.conf. 配置 named.conf 中的目录区域。

Catalog zones are configured with a catalog-zones statement in the options or view section of named.conf. For example: 目录区域在 named.conf 的 options 或 view 部分配置了 catalog-zones 语句。例如：

catalog-zones {
    zone "catalog.example"
         default-primaries { 10.53.0.1; }
         in-memory no
         zone-directory "catzones"
         min-update-interval 10;
};

This statement specifies that the zone catalog.example is a catalog zone. This zone must be properly configured in the same view. In most configurations, it would be a secondary zone. 此语句指定区域 catalog.example 是目录区域。此区域必须在同一视图中正确配置。在大多数配置中，它将是次要区域。

The options following the zone name are not required, and may be specified in any order. 区域名称后面的选项不是必需的，可以按任何顺序指定。

• default-masters

  Synonym for default-primaries. default-primaries 的同义词。

• default-primaries

  This option defines the default primaries for member zones listed in a catalog zone, and can be overridden by options within a catalog zone. If no such options are included, then member zones transfer their contents from the servers listed in this option. 此选项定义目录区域中列出的成员区域的默认主色，并且可以被目录区域中的选项覆盖。如果没有包含此类选项，则成员区域将从该选项中列出的服务器传输其内容。

• in-memory

  This option, if set to yes, causes member zones to be stored only in memory. This is functionally equivalent to configuring a secondary zone without a file option. The default is no; member zones’ content is stored locally in a file whose name is automatically generated from the view name, catalog zone name, and member zone name. 如果将此选项设置为 yes ，则会导致成员区域仅存储在内存中。这在功能上等同于配置一个没有 file 选项的辅助区域。默认为 no ；成员区域的内容本地存储在一个文件中，该文件的名称是根据视图名称、目录区域名称和成员区域名称自动生成的。

• zone-directory

  This option causes local copies of member zones’ zone files to be stored in the specified directory, if in-memory is not set to yes. The default is to store zone files in the server’s working directory. A non-absolute pathname in zone-directory is assumed to be relative to the working directory. 如果 in-memory 未设置为 yes ，则此选项会导致成员区域文件的本地副本存储在指定目录中。默认是将区域文件存储在服务器的工作目录中。 zone-directory 中的非绝对路径名被假定为相对于工作目录。

• min-update-interval

  This option sets the minimum interval between updates to catalog zones, in seconds. If an update to a catalog zone (for example, via IXFR) happens less than min-update-interval seconds after the most recent update, the changes are not carried out until this interval has elapsed. The default is 5 seconds. 此选项设置目录区域更新之间的最小间隔，以秒为单位。如果对目录区域的更新（例如，通过 IXFR）发生在最近更新后不到 min-update-interval 秒，则更改不会执行，直到该时间间隔过去。默认值为 5 秒。

Catalog zones are defined on a per-view basis. Configuring a non-empty catalog-zones statement in a view automatically turns on allow-new-zones for that view. This means that rndc addzone and rndc delzone also work in any view that supports catalog zones. 目录区域是在每个视图的基础上定义的。在视图中配置非空 catalog-zones 语句会自动为该视图打开 allow-new-zones 。这意味着 rndc addzone 和 rndc delzone 也适用于任何支持目录区域的视图。

6.8.3. Catalog Zone Format 6.8.3.目录区格式 

A catalog zone is a regular DNS zone; therefore, it must have a single SOA and at least one NS record. 目录区域是常规 DNS 区域；因此，它必须有一个 SOA 和至少一个 NS 记录。

A record stating the version of the catalog zone format is also required. If the version number listed is not supported by the server, then a catalog zone may not be used by that server. 还需要一份说明目录区域格式版本的记录。如果服务器不支持列出的版本号，则该服务器可能不使用目录区域。

catalog.example.    IN SOA . . 2016022901 900 600 86400 1
catalog.example.    IN NS invalid.
version.catalog.example.    IN TXT "2"

Note that this record must have the domain name version.catalog-zone-name. The data stored in a catalog zone is indicated by the domain name label immediately before the catalog zone domain. Currently BIND supports catalog zone schema versions “1” and “2”. 请注意，此记录必须具有域名 version.catalog-zone-name 。存储在目录区域中的数据由紧接在目录区域域之前的域名标签指示。当前 BIND 支持目录区域架构版本“1”和“2”。

Also note that the catalog zone must have an NS record in order to be a valid DNS zone, and using the value “invalid.” for NS is recommended. 另请注意，目录区域必须具有 NS 记录才能成为有效的 DNS 区域，并使用值“无效”。推荐用于 NS。

A member zone is added by including a PTR resource record in the zones sub-domain of the catalog zone. The record label can be any unique label. The target of the PTR record is the member zone name. For example, to add member zones domain.example and domain2.example: 通过在目录区域的 zones 子域中包含 PTR 资源记录来添加成员区域。记录标签可以是任何唯一标签。 PTR 记录的目标是会员区名称。例如，添加成员区域 domain.example 和 domain2.example ：

5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN PTR domain.example.
uniquelabel.zones.catalog.example. IN PTR domain2.example.

The label is necessary to identify custom properties (see below) for a specific member zone. Also, the zone state can be reset by changing its label, in which case BIND will remove the member zone and add it back. 该标签是识别特定成员区域的自定义属性（见下文）所必需的。此外，区域状态可以通过更改其标签来重置，在这种情况下，BIND 将删除成员区域并将其添加回来。

6.8.4. Catalog Zone Custom Properties 6.8.4.目录区自定义属性 

BIND uses catalog zones custom properties to define different properties which can be set either globally for the whole catalog zone or for a single member zone. BIND 使用目录区域自定义属性来定义不同的属性，这些属性可以为整个目录区域或单个成员区域全局设置。 Global custom properties override the settings in the configuration file, and member zone custom properties override global custom properties. 全局自定义属性覆盖配置文件中的设置，成员区自定义属性覆盖全局自定义属性。

For the version “1” of the schema custom properties must be placed without a special suffix. 对于模式自定义属性的版本“1”，必须在没有特殊后缀的情况下放置。

For the version “2” of the schema custom properties must be placed under the “.ext” suffix. 对于模式自定义属性的版本“2”，必须放在“.ext”后缀下。

Global custom properties are set at the apex of the catalog zone, e.g.: 全局自定义属性设置在目录区域的顶点，例如：

primaries.ext.catalog.example.    IN AAAA 2001:db8::1

BIND currently supports the following custom properties: BIND 当前支持以下自定义属性：

• A simple primaries definition: 一个简单的 primaries 定义：

  primaries.ext.catalog.example.    IN A 192.0.2.1

  This custom property defines a primary server for the member zones, which can be either an A or AAAA record. If multiple primaries are set, the order in which they are used is random. 此自定义属性为成员区域定义主服务器，它可以是 A 或 AAAA 记录。如果设置了多个原色，它们的使用顺序是随机的。

  Note: masters can be used as a synonym for primaries. 注意： masters 可以用作 primaries 的同义词。

• A primaries with a TSIG key defined: 定义了 TSIG 密钥的 primaries ：

  label.primaries.ext.catalog.example.     IN A 192.0.2.2
  label.primaries.ext.catalog.example.     IN TXT "tsig_key_name"

  This custom property defines a primary server for the member zone with a TSIG key set. The TSIG key must be configured in the configuration file. label can be any valid DNS label. 此自定义属性为具有 TSIG 密钥集的成员区域定义主服务器。必须在配置文件中配置 TSIG 密钥。 label 可以是任何有效的 DNS 标签。

  Note: masters can be used as a synonym for primaries. 注意： masters 可以用作 primaries 的同义词。

• allow-query and allow-transfer ACLs: allow-query 和 allow-transfer ACL：

  allow-query.ext.catalog.example.   IN APL 1:10.0.0.1/24
  allow-transfer.ext.catalog.example.    IN APL !1:10.0.0.1/32 1:10.0.0.0/24

  These custom properties are the equivalents of allow-query and allow-transfer options in a zone declaration in the named.conf configuration file. The ACL is processed in order; if there is no match to any rule, the default policy is to deny access. For the syntax of the APL RR, see RFC 3123. 这些自定义属性等同于 named.conf 配置文件中区域声明中的 allow-query 和 allow-transfer 选项。 ACL是按顺序处理的；如果没有匹配到任何规则，则默认策略是拒绝访问。有关 APL RR 的语法，请参阅 RFC 3123。

The member zone-specific custom properties are defined the same way as global custom properties, but in the member zone subdomain: 特定于成员区域的自定义属性的定义方式与全局自定义属性相同，但在成员区域子域中：

primaries.ext.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN A 192.0.2.2
label.primaries.ext.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN AAAA 2001:db8::2
label.primaries.ext.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN TXT "tsig_key_name"
allow-query.ext.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN APL 1:10.0.0.0/24
primaries.ext.uniquelabel.zones.catalog.example. IN A 192.0.2.3

Custom properties defined for a specific zone override the global custom properties defined in the catalog zone. These in turn override the global options defined in the catalog-zones statement in the configuration file. 为特定区域定义的自定义属性会覆盖目录区域中定义的全局自定义属性。这些依次覆盖配置文件中 catalog-zones 语句中定义的全局选项。

Note that none of the global records for a custom property are inherited if any records are defined for that custom property for the specific zone. For example, if the zone had a primaries record of type A but not AAAA, it would not inherit the type AAAA record from the global custom property or from the global option in the configuration file. 请注意，如果为特定区域的自定义属性定义了任何记录，则不会继承自定义属性的任何全局记录。例如，如果该区域有一个类型为 A 而不是 AAAA 的 primaries 记录，则它不会从全局自定义属性或配置文件中的全局选项继承类型 AAAA 记录。

6.8.5. Change of Ownership (coo) 6.8.5.所有权变更 (coo) 

BIND supports the catalog zones “Change of Ownership” (coo) property. BIND 支持目录区域“所有权变更”(coo) 属性。 When the same entry which exists in one catalog zone is added into another catalog zone, the default behavior for BIND is to ignore it, and continue serving the zone using the catalog zone where it was originally existed, unless it is removed from there, then it can be added into the new one. 当一个目录区域中存在的相同条目被添加到另一个目录区域时，BIND 的默认行为是忽略它，并继续使用它最初存在的目录区域为该区域提供服务，除非它从那里被删除，然后它可以添加到新的。

Using the coo property it is possible to gracefully move a zone from one catalog zone into another, by letting the catalog consumers know that it is permitted to do so. To do that, the original catalog zone should be updated with a new record with coo custom property: 使用 coo 属性可以优雅地将区域从一个目录区域移动到另一个目录区域，方法是让目录使用者知道这样做是被允许的。为此，应使用具有 coo 自定义属性的新记录更新原始目录区域：

uniquelabel.zones.catalog.example. IN PTR domain2.example.
coo.uniquelabel.zones.catalog.example. IN PTR catalog2.example.

Here, the catalog.example catalog zone gives permission for the member zone with label “uniquelabel” to be transferred into catalog2.example catalog zone. Catalog consumers which support the coo property will then take note, and when the zone is finally added into catalog2.example catalog zone, catalog consumers will change the ownership of the zone from catalog.example to catalog2.example. BIND’s implementation simply deletes the zone from the old catalog zone and adds it back into the new catalog zone, which also means that all associated state for the just migrated zone will be reset, including when the unique label is the same. 此处， catalog.example 目录区域允许将标签为“uniquelabel”的成员区域转移到 catalog2.example 目录区域。支持 coo 属性的目录消费者随后会注意到，当区域最终添加到 catalog2.example 目录区域时，目录消费者会​​将区域的所有权从 catalog.example 更改为 catalog2.example 。 BIND 的实现只是从旧的目录区域中删除区域并将其添加回新的目录区域，这也意味着刚刚迁移的区域的所有关联状态都将被重置，包括唯一标签相同的情况。

The record with coo custom property can be later deleted by the catalog zone operator after confirming that all the consumers have received it and have successfully changed the ownership of the zone. 具有 coo 自定义属性的记录可以在确认所有消费者都收到并成功更改区域所有权后由目录区域操作员稍后删除。

6.9. DNS Firewalls and Response Policy Zones 6.9. DNS 防火墙和响应策略区域 

A DNS firewall examines DNS traffic and allows some responses to pass through while blocking others. DNS 防火墙检查 DNS 流量并允许某些响应通过而阻止其他响应。 This examination can be based on several criteria, including the name requested, the data (such as an IP address) associated with that name, or the name or IP address of the name server that is authoritative for the requested name. 该检查可以基于多个标准，包括请求的名称、与该名称关联的数据（例如 IP 地址），或者对请求的名称具有权威性的名称服务器的名称或 IP 地址。 Based on these criteria, a DNS firewall can be configured to discard, modify, or replace the original response, allowing administrators more control over what systems can access or be accessed from their networks. 基于这些标准，DNS 防火墙可以配置为丢弃、修改或替换原始响应，从而允许管理员更好地控制哪些系统可以访问或从他们的网络访问哪些系统。

DNS Response Policy Zones (RPZ) are a form of DNS firewall in which the firewall rules are expressed within the DNS itself – encoded in an open, vendor-neutral format as records in specially constructed DNS zones. DNS 响应策略区域 (RPZ) 是 DNS 防火墙的一种形式，其中防火墙规则在 DNS 本身内表达 – 以开放的、供应商中立的格式编码为专门构建的 DNS 区域中的记录。

Using DNS zones to configure policy allows policy to be shared from one server to another using the standard DNS zone transfer mechanism. This allows a DNS operator to maintain their own firewall policies and share them easily amongst their internal name servers, or to subscribe to external firewall policies such as commercial or cooperative “threat feeds,” or both. 使用 DNS 区域配置策略允许使用标准 DNS 区域传输机制将策略从一台服务器共享到另一台服务器。这允许 DNS 运营商维护他们自己的防火墙策略并在其内部名称服务器之间轻松共享它们，或者订阅外部防火墙策略，例如商业或合作“威胁源”，或两者兼而有之。

named can subscribe to up to 64 Response Policy Zones, each of which encodes a separate policy rule set. Each rule is stored in a DNS resource record set (RRset) within the RPZ, and consists of a trigger and an action. There are five types of triggers and six types of actions. named 最多可以订阅 64 个 Response Policy Zones，每个 Response Policy Zones 编码一个单独的策略规则集。每个规则都存储在 RPZ 内的 DNS 资源记录集 (RRset) 中，并由触发器和操作组成。有五种类型的触发器和六种类型的操作。

A response policy rule in a DNS RPZ can be triggered as follows: DNS RPZ 中的响应策略规则可以按如下方式触发：

• by the IP address of the client 通过客户端的IP地址
• by the query name 通过查询名称
• by an address which would be present in a truthful response 通过将出现在真实响应中的地址
• by the name or address of an authoritative name server responsible for publishing the original response 通过负责发布原始响应的权威名称服务器的名称或地址

A response policy action can be one of the following: 响应策略操作可以是以下之一：

• to synthesize a “domain does not exist” (NXDOMAIN) response 合成一个“域不存在”（NXDOMAIN）响应
• to synthesize a “name exists but there are no records of the requested type” (NODATA) response 合成一个“名称存在但没有请求类型的记录”（NODATA）响应
• to drop the response 放弃回应
• to switch to TCP by sending a truncated UDP response that requires the DNS client to try again with TCP 通过发送截断的 UDP 响应来切换到 TCP，该响应要求 DNS 客户端再次尝试使用 TCP
• to replace/override the response’s data with specific data (provided within the response policy zone) 用特定数据替换/覆盖响应数据（在响应策略区域内提供）
• to exempt the response from further policy processing 免除进一步政策处理的回应

The most common use of a DNS firewall is to “poison” a domain name, IP address, name server name, or name server IP address. DNS 防火墙最常见的用途是“毒化”域名、IP 地址、名称服务器名称或名称服务器 IP 地址。 Poisoning is usually done by forcing a synthetic “domain does not exist” (NXDOMAIN) response. This means that if an administrator maintains a list of known “phishing” domains, these names can be made unreachable by customers or end users just by adding a firewall policy into the recursive DNS server, with a trigger for each known “phishing” domain, and an action in every case forcing a synthetic NXDOMAIN response. 中毒通常是通过强制合成“域不存在”(NXDOMAIN) 响应来完成的。这意味着，如果管理员维护一个已知“网络钓鱼”域的列表，只需将防火墙策略添加到递归 DNS 服务器，并为每个已知的“网络钓鱼”域触发，客户或最终用户就可以使这些名称无法访问，以及在每种情况下强制合成 NXDOMAIN 响应的操作。 It is also possible to use a data-replacement action such as answering for these known “phishing” domains with the name of a local web server that can display a warning page. Such a web server would be called a “walled garden.” 也可以使用数据替换操作，例如使用可以显示警告页面的本地 Web 服务器的名称来回答这些已知的“网络钓鱼”域。这样的 Web 服务器将被称为“围墙花园”。

Note

Authoritative name servers can be responsible for many different domains. If DNS RPZ is used to poison all domains served by some authoritative name server name or address, the effects can be quite far-reaching. 权威名称服务器可以负责许多不同的域。如果使用 DNS RPZ 来毒化由某些权威名称服务器名称或地址提供服务的所有域，其影响可能会非常深远。 Users are advised to ensure that such authoritative name servers do not also serve domains that should not be poisoned. 建议用户确保此类权威名称服务器不会同时服务于不应中毒的域。

6.9.1. Why Use a DNS Firewall? 6.9.1.为什么要使用 DNS 防火墙？ 

Criminal and network abuse traffic on the Internet often uses the Domain Name System (DNS), so protection against these threats should include DNS firewalling. 互联网上的犯罪和网络滥用流量通常使用域名系统 (DNS)，因此针对这些威胁的保护措施应包括 DNS 防火墙。 A DNS firewall can selectively intercept DNS queries for known network assets including domain names, IP addresses, and name servers. DNS 防火墙可以选择性地拦截对已知网络资产（包括域名、IP 地址和名称服务器）的 DNS 查询。 Interception can mean rewriting a DNS response to direct a web browser to a “walled garden,” or simply making any malicious network assets invisible and unreachable. 拦截可能意味着重写 DNS 响应以将 Web 浏览器定向到“围墙花园”，或者只是让任何恶意网络资产不可见且无法访问。

6.9.2. What Can a DNS Firewall Do? 6.9.2. DNS 防火墙可以做什么？ 

Firewalls work by applying a set of rules to a traffic flow, where each rule consists of a trigger and an action. Triggers determine which messages within the traffic flow are handled specially, and actions determine what that special handling is. 防火墙通过将一组规则应用于流量来工作，其中每个规则都包含一个触发器和一个操作。触发器确定流量流中的哪些消息被特殊处理，而操作确定特殊处理是什么。 For a DNS firewall, the traffic flow to be controlled consists of responses sent by a recursive DNS server to its end-user clients. 对于 DNS 防火墙，要控制的流量由递归 DNS 服务器发送到其最终用户客户端的响应组成。 Some true responses are not safe for all clients, so the policy rules in a DNS firewall allow some responses to be intercepted and replaced with safer content. 某些真正的响应对所有客户端而言并不安全，因此 DNS 防火墙中的策略规则允许拦截某些响应并将其替换为更安全的内容。

6.9.3. Creating and Maintaining RPZ Rule Sets 6.9.3.创建和维护 RPZ 规则集 

In DNS RPZ, the DNS firewall policy rule set is stored in a DNS zone, which is maintained and synchronized using the same tools and methods as for any other DNS zone. 在 DNS RPZ 中，DNS 防火墙策略规则集存储在 DNS 区域中，该区域使用与任何其他 DNS 区域相同的工具和方法进行维护和同步。 The primary name server for a DNS RPZ may be an internal server, if an administrator is creating and maintaining their own DNS policy zone, or it may be an external name server (such as a security vendor’s server), if importing a policy zone published externally. DNS RPZ 的主要名称服务器可以是内部服务器，如果管理员正在创建和维护他们自己的 DNS 策略区域，或者它可以是外部名称服务器（例如安全供应商的服务器），如果导入已发布的策略区域在外部。 The primary copy of the DNS firewall policy can be a DNS “zone file” which is either edited by hand or generated from a database. A DNS zone can also be edited indirectly using DNS dynamic updates (for example, using the “nsupdate” shell level utility). DNS 防火墙策略的主要副本可以是手动编辑或从数据库生成的 DNS“区域文件”。还可以使用 DNS 动态更新间接编辑 DNS 区域（例如，使用“nsupdate”shell 级实用程序）。

DNS RPZ allows firewall rules to be expressed in a DNS zone format and then carried to subscribers as DNS data. DNS RPZ 允许防火墙规则以 DNS 区域格式表示，然后作为 DNS 数据传送给订阅者。 A recursive DNS server which is capable of processing DNS RPZ synchronizes these DNS firewall rules using the same standard DNS tools and protocols used for secondary name service. 能够处理 DNS RPZ 的递归 DNS 服务器使用与二级名称服务相同的标准 DNS 工具和协议来同步这些 DNS 防火墙规则。 The DNS policy information is then promoted to the DNS control plane inside the customer’s DNS resolver, making that server into a DNS firewall. 然后将 DNS 策略信息提升到客户 DNS 解析器内的 DNS 控制平面，使该服务器成为 DNS 防火墙。

A security company whose products include threat intelligence feeds can use a DNS Response Policy Zone (RPZ) as a delivery channel to customers. Threats can be expressed as known-malicious IP addresses and subnets, known-malicious domain names, and known-malicious domain name servers. 其产品包含威胁情报源的安全公司可以使用 DNS 响应策略区 (RPZ) 作为向客户的交付渠道。威胁可以表示为已知恶意IP地址和子网、已知恶意域名和已知恶意域名服务器。 By feeding this threat information directly into customers’ local DNS resolvers, providers can transform these DNS servers into a distributed DNS firewall. 通过将此威胁信息直接输入客户的本地 DNS 解析器，提供商可以将这些 DNS 服务器转换为分布式 DNS 防火墙。

When a customer’s DNS resolver is connected by a realtime subscription to a threat intelligence feed, the provider can protect the customer’s end users from malicious network elements (including IP addresses and subnets, domain names, and name servers) immediately as they are discovered. 当客户的 DNS 解析器通过实时订阅威胁情报源连接时，提供商可以在发现恶意网络元素（包括 IP 地址和子网、域名和名称服务器）时立即保护客户的最终用户免受恶意网络元素的侵害。 While it may take days or weeks to “take down” criminal and abusive infrastructure once reported, a distributed DNS firewall can respond instantly. 虽然一旦收到报告可能需要数天或数周时间才能“关闭”犯罪和滥用基础设施，但分布式 DNS 防火墙可以立即做出响应。

Other distributed TCP/IP firewalls have been on the market for many years, and enterprise users are now comfortable importing real-time threat intelligence from their security vendors directly into their firewalls. This intelligence can take the form of known-malicious IP addresses or subnets, or of patterns which identify known-malicious email attachments, file downloads, or web addresses (URLs). 其他分布式 TCP/IP 防火墙已经上市多年，企业用户现在可以轻松地将来自其安全供应商的实时威胁情报直接导入到他们的防火墙中。这种情报可以采用已知恶意 IP 地址或子网的形式，或者采用识别已知恶意电子邮件附件、文件下载或网址 (URL) 的模式的形式。 In some products it is also possible to block DNS packets based on the names or addresses they carry. 在某些产品中，还可以根据它们携带的名称或地址来阻止 DNS 数据包。

6.9.4. Limitations of DNS RPZ 6.9.4. DNS RPZ 的限制 

We’re often asked if DNS RPZ could be used to set up redirection to a CDN. For example, if “mydomain.com” is a normal domain with SOA, NS, MX, TXT records etc., then if someone sends an A or AAAA query for “mydomain.com”, can we use DNS RPZ on an authoritative nameserver to return “CNAME mydomain.com.my-cdn-provider.net”? 我们经常被问及 DNS RPZ 是否可用于设置到 CDN 的重定向。例如，如果“mydomain.com”是一个普通域，有 SOA、NS、MX、TXT 等记录，那么如果有人向“mydomain.com”发送 A 或 AAAA 查询，我们是否可以在权威名称服务器上使用 DNS RPZ返回“CNAME mydomain.com.my-cdn-provider.net”？

The problem with this suggestion is that there is no way to CNAME only A and AAAA queries, not even with RPZ. 这个建议的问题是没有办法只对 A 和 AAAA 查询进行 CNAME，即使使用 RPZ 也是如此。

The underlying reason is that if the authoritative server answers with a CNAME, the recursive server making that query will cache the response. Thereafter (while the CNAME is still in cache), it assumes that there are no records of any non-CNAME type for the name that was being queried, and directs subsequent queries for all other types directly to the target name of the CNAME record. 根本原因是，如果权威服务器使用 CNAME 进行回答，则进行该查询的递归服务器将缓存响应。此后（当 CNAME 仍在缓存中时），它假定所查询的名称没有任何非 CNAME 类型的记录，并将所有其他类型的后续查询直接定向到 CNAME 记录的目标名称。

To be clear, this is not a limitation of RPZ; it is a function of the way the DNS protocol works. It’s simply not possible to use “partial” CNAMES to help when setting up CDNs because doing this will break other functionality such as email routing. 需要明确的是，这不是 RPZ 的限制；它是 DNS 协议工作方式的函数。在设置 CDN 时，根本不可能使用“部分”CNAMES 来提供帮助，因为这样做会破坏其他功能，例如电子邮件路由。

Similarly, following the DNS protocol definition, wildcards in the form of *.example records might behave in unintuitive ways. For a detailed definition of wildcards in DNS, please see RFC 4592, especially section 2. 同样，按照 DNS 协议定义， *.example 记录形式的通配符可能会以不直观的方式运行。有关 DNS 中通配符的详细定义，请参阅 RFC 4592，尤其是第 2 节。

6.9.5. DNS Firewall Usage Examples 6.9.5. DNS 防火墙使用示例 

Here are some scenarios in which a DNS firewall might be useful. 以下是 DNS 防火墙可能有用的一些场景。

Some known threats are based on an IP address or subnet (IP address range). For example, an analysis may show that all addresses in a “class C” network are used by a criminal gang for “phishing” web servers. 一些已知威胁基于 IP 地址或子网（IP 地址范围）。例如，分析可能表明“C 类”网络中的所有地址都被犯罪团伙用于“网络钓鱼”Web 服务器。 With a DNS firewall based on DNS RPZ, a firewall policy can be created such as “if a DNS lookup would result in an address from this class C network, then answer instead with an NXDOMAIN indication.” That simple rule would prevent any end users inside customers’ networks from being able to look up any domain name used in this phishing attack – without having to know in advance what those names might be. 使用基于 DNS RPZ 的 DNS 防火墙，可以创建防火墙策略，例如“如果 DNS 查找会导致来自此类 C 网络的地址，则使用 NXDOMAIN 指示进行应答。”这个简单的规则将阻止客户网络内的任何最终用户能够查找此网络钓鱼攻击中使用的任何域名——而无需事先知道这些名称可能是什么。

Other known threats are based on domain names. An analysis may determine that a certain domain name or set of domain names is being or will shortly be used for spamming, phishing, or other Internet-based attacks which all require working domain names. 其他已知威胁基于域名。分析可能会确定某个域名或一组域名正被或即将被用于垃圾邮件、网络钓鱼或其他基于 Internet 的攻击，这些都需要有效的域名。 By adding name-triggered rules to a distributed DNS firewall, providers can protect customers’ end users from any attacks which require them to be able to look up any of these malicious names. 通过向分布式 DNS 防火墙添加名称触发规则，提供商可以保护客户的最终用户免受任何需要他们能够查找这些恶意名称的攻击。 The names can be wildcards (for example, *.evil.com), and these wildcards can have exceptions if some domains are not as malicious as others (if *.evil.com is bad, then not.evil.com might be an exception). 名称可以是通配符（例如 *.evil.com），如果某些域不像其他域那么恶意（如果 *.evil.com 是坏的，那么 not.evil.com 可能是例外）。

Alongside growth in electronic crime has come growth of electronic criminal expertise. Many criminal gangs now maintain their own extensive DNS infrastructure to support a large number of domain names and a diverse set of IP addressing resources. 随着电子犯罪的增长，电子犯罪专业知识也在增长。许多犯罪团伙现在维护着自己广泛的 DNS 基础设施，以支持大量域名和多样化的 IP 寻址资源集。 Analyses show in many cases that the only truly fixed assets criminal organizations have are their name servers, which are by nature slightly less mobile than other network assets. 分析表明，在许多情况下，犯罪组织唯一真正拥有的固定资产是它们的名称服务器，它们的移动性在本质上略低于其他网络资产。 In such cases, DNS administrators can anchor their DNS firewall policies in the abusive name server names or name server addresses, and thus protect their customers’ end users from threats where neither the domain name nor the IP address of that threat is known in advance. 在这种情况下，DNS 管理员可以将他们的 DNS 防火墙策略锚定在滥用的名称服务器名称或名称服务器地址中，从而保护他们客户的最终用户免受威胁，而这些威胁的域名和 IP 地址都是事先不知道的。

Electronic criminals rely on the full resiliency of DNS just as the rest of digital society does. By targeting criminal assets at the DNS level we can deny these criminals the resilience they need. 正如数字社会的其他部分一样，电子罪犯也依赖 DNS 的充分弹性。通过在 DNS 级别锁定犯罪资产，我们可以剥夺这些犯罪分子所需的弹性。 A distributed DNS firewall can leverage the high skills of a security company to protect a large number of end users. DNS RPZ, as the first open and vendor-neutral distributed DNS firewall, can be an effective way to deliver threat intelligence to customers. 分布式 DNS 防火墙可以利用安全公司的高技能来保护大量最终用户。 DNS RPZ 作为第一个开放且供应商中立的分布式 DNS 防火墙，可以成为向客户提供威胁情报的有效方式。

6.9.5.1. A Real-World Example of DNS RPZ’s Value 6.9.5.1。 DNS RPZ 价值的真实示例 

The Conficker malware worm (https://en.wikipedia.org/wiki/Conficker) was first detected in 2008. Although it is no longer an active threat, the techniques described here can be applied to other DNS threats. Conficker 恶意软件蠕虫 (https://en.wikipedia.org/wiki/Conficker) 于 2008 年首次被发现。虽然它不再是一个活跃的威胁，但此处描述的技术可应用于其他 DNS 威胁。

Conficker used a domain generation algorithm (DGA) to choose up to 50,000 command and control domains per day. It would be impractical to create an RPZ that contains so many domain names and changes so much on a daily basis. Conficker 使用域生成算法 (DGA) 每天选择多达 50,000 个命令和控制域。创建一个包含如此多域名且每天变化如此之多的 RPZ 是不切实际的。 Instead, we can trigger RPZ rules based on the names of the name servers that are authoritative for the command and control domains, rather than trying to trigger on each of 50,000 different (daily) query names. Since the well-known name server names for Conficker’s domain names are never used by nonmalicious domains, it is safe to poison all lookups that rely on these name servers. 相反，我们可以根据对命令和控制域具有权威性的名称服务器名称触发 RPZ 规则，而不是尝试在 50,000 个不同（每日）查询名称中的每一个上触发。由于 Conficker 域名的知名名称服务器名称从未被非恶意域使用，因此可以安全地毒化所有依赖这些名称服务器的查找。 Here is an example that achieves this result: 这是实现此结果的示例：

$ORIGIN rpz.example.com.
ns.0xc0f1c3a5.com.rpz-nsdname  CNAME  *.walled-garden.example.com.
ns.0xc0f1c3a5.net.rpz-nsdname  CNAME  *.walled-garden.example.com.
ns.0xc0f1c3a5.org.rpz-nsdname  CNAME  *.walled-garden.example.com.

The * at the beginning of these CNAME target names is special, and it causes the original query name to be prepended to the CNAME target. So if a user tries to visit the Conficker command and control domain http://racaldftn.com.ai/ (which was a valid Conficker command and control domain name on 19-October-2011), the RPZ-configured recursive name server will send back this answer: 这些 CNAME 目标名称开头的 * 是特殊的，它会导致将原始查询名称添加到 CNAME 目标之前。因此，如果用户尝试访问 Conficker 命令和控制域 http://racaldftn.com.ai/（这是 2011 年 10 月 19 日的有效 Conficker 命令和控制域名），RPZ 配置的递归名称服务器将发回这个答案：

racaldftn.com.ai.     CNAME     racaldftn.com.ai.walled-garden.example.com.
racaldftn.com.ai.walled-garden.example.com.     A      192.168.50.3

This example presumes that the following DNS content has also been created, which is not part of the RPZ zone itself but is in another domain: 此示例假定还创建了以下 DNS 内容，它不是 RPZ 区域本身的一部分，而是在另一个域中：

$ORIGIN walled-garden.example.com.
*     A     192.168.50.3

Assuming that we’re running a web server listening on 192.168.50.3 that always displays a warning message no matter what uniform resource identifier (URI) is used, the above RPZ configuration will instruct the web browser of any infected end user to connect to a “server name” consisting of their original lookup name (racaldftn.com.ai) prepended to the walled garden domain name (walled-garden.example.com). 假设我们正在运行一个侦听 192.168.50.3 的 Web 服务器，无论使用什么统一资源标识符 (URI)，它始终显示一条警告消息，上述 RPZ 配置将指示任何受感染的最终用户的 Web 浏览器连接到一个“服务器名称”由其原始查找名称 (racaldftn.com.ai) 和围墙花园域名 (walled-garden.example.com) 组成。 This is the name that will appear in the web server’s log file, and having the full name in that log file will facilitate an analysis as to which users are infected with what virus. 这是将出现在 Web 服务器日志文件中的名称，在该日志文件中包含完整名称将有助于分析哪些用户感染了何种病毒。

6.9.6. Keeping Firewall Policies Updated 6.9.6.保持防火墙策略更新 

It is vital for overall system performance that incremental zone transfers (see RFC 1995) and real-time change notification (see RFC 1996) be used to synchronize DNS firewall rule sets between the publisher’s primary copy of the rule set and the subscribers’ working copies of the rule set. 增量区域传输（请参阅 RFC 1995）和实时更改通知（请参阅 RFC 1996）用于在发布者的规则集主副本与订阅者的工作副本之间同步 DNS 防火墙规则集对于整体系统性能至关重要的规则集。

If DNS dynamic updates are used to maintain a DNS RPZ rule set, the name server automatically calculates a stream of deltas for use when sending incremental zone transfers to the subscribing name servers. 如果使用 DNS 动态更新来维护 DNS RPZ 规则集，名称服务器会自动计算增量流，以便在将增量区域传输发送到订阅名称服务器时使用。 Sending a stream of deltas – known as an “incremental zone transfer” or IXFR – is usually much faster than sending the full zone every time it changes, so it’s worth the effort to use an editing method that makes such incremental transfers possible. 发送增量流（称为“增量区域传输”或 IXFR）通常比每次更改时发送整个区域快得多，因此值得努力使用使这种增量传输成为可能的编辑方法。

Administrators who edit or periodically regenerate a DNS RPZ rule set and whose primary name server uses BIND can enable the ixfr-from-differences option, which tells the primary name server to calculate the differences between each new zone and the preceding version, and to make these differences available as a stream of deltas for use in incremental zone transfers to the subscribing name servers. 编辑或定期重新生成 DNS RPZ 规则集且其主名称服务器使用 BIND 的管理员可以启用 ixfr-from-differences 选项，该选项告诉主名称服务器计算每个新区域与先前版本之间的差异，并将这些差异可用作增量区域传输到订阅名称服务器的增量流。 This will look something like the following: 这将类似于以下内容：

options {
          // ...
          ixfr-from-differences yes;
          // ...
};

As mentioned above, the simplest and most common use of a DNS firewall is to poison domain names known to be purely malicious, by simply making them disappear. 如上所述，DNS 防火墙最简单和最常见的用途是毒化已知的纯恶意域名，方法是让它们消失。 All DNS RPZ rules are expressed as resource record sets (RRsets), and the way to express a “force a name-does-not-exist condition” is by adding a CNAME pointing to the root domain (.). In practice this looks like: 所有 DNS RPZ 规则都表示为资源记录集 (RRsets)，表示“强制名称不存在条件”的方式是添加指向根域 ( . ) 的 CNAME。在实践中，这看起来像：

$ORIGIN rpz.example.com.
malicious1.org          CNAME .
*.malicious1.org        CNAME .
malicious2.org          CNAME .
*.malicious2.org        CNAME .

Two things are noteworthy in this example. First, the malicious names are made relative within the response policy zone. Since there is no trailing dot following “.org” in the above example, the actual RRsets created within this response policy zone are, after expansion: 这个例子中有两点值得注意。首先，恶意名称在响应策略区内是相对的。由于上例中“.org”后没有尾随点，因此在此响应策略区内创建的实际 RRset 在扩展后为：

malicious1.org.rpz.example.com.         CNAME .
*.malicious1.org.rpz.example.com.       CNAME .
malicious2.org.rpz.example.com.         CNAME .
*.malicious2.org.rpz.example.com.       CNAME .

Second, for each name being poisoned, a wildcard name is also listed. This is because a malicious domain name probably has or may potentially have malicious subdomains. 其次，对于每个中毒的名称，还列出了一个通配符名称。这是因为恶意域名可能具有或可能具有恶意子域。

In the above example, the relative domain names malicious1.org and malicious2.org will match only the real domain names malicious1.org and malicious2.org, respectively. The relative domain names *.malicious1.org and *.malicious2.org will match any subdomain.of.malicious1.org or subdomain.of.malicious2.org, respectively. 在上面的示例中，相对域名 malicious1.org 和 malicious2.org 将分别仅匹配真实域名 malicious1.org 和 malicious2.org。相对域名 *.malicious1.org 和 *.malicious2.org 将分别匹配任何 subdomain.of.malicious1.org 或 subdomain.of.malicious2.org。

This example forces an NXDOMAIN condition as its policy action, but other policy actions are also possible. 此示例强制 NXDOMAIN 条件作为其策略操作，但其他策略操作也是可能的。

6.9.7. Performance and Scalability When Using Multiple RPZs 6.9.7.使用多个 RPZ 时的性能和可扩展性

Since version 9.10, BIND can be configured to have different response policies depending on the identity of the querying client and the nature of the query. 从 9.10 版本开始，BIND 可以根据查询客户端的身份和查询的性质配置为具有不同的响应策略。 To configure BIND response policy, the information is placed into a zone file whose only purpose is conveying the policy information to BIND. 要配置 BIND 响应策略，将信息放入一个区域文件中，该文件的唯一目的是将策略信息传递给 BIND。 A zone file containing response policy information is called a Response Policy Zone, or RPZ, and the mechanism in BIND that uses the information in those zones is called DNS RPZ. 包含响应策略信息的区域文件称为响应策略区域或 RPZ，BIND 中使用这些区域中的信息的机制称为 DNS RPZ。

It is possible to use as many as 64 separate RPZ files in a single instance of BIND, and BIND is not significantly slowed by such heavy use of RPZ. 在 BIND 的单个实例中可以使用多达 64 个单独的 RPZ 文件，并且 BIND 不会因如此大量使用 RPZ 而显着变慢。

(Note: by default, BIND 9.11 only supports up to 32 RPZ files, but this can be increased to 64 at compile time. All other supported versions of BIND support 64 by default.) （注意：默认情况下，BIND 9.11 最多只支持 32 个 RPZ 文件，但在编译时可以增加到 64 个。所有其他支持的 BIND 版本默认支持 64 个。）

Each one of the policy zone files can specify policy for as many different domains as necessary. The limit of 64 is on the number of independently-specified policy collections and not the number of zones for which they specify policy. 每个策略区域文件都可以根据需要为尽可能多的不同域指定策略。 64 的限制是针对独立指定的策略集合的数量，而不是它们为其指定策略的区域的数量。

Policy information from all of the policy zones together are stored in a special data structure allowing simultaneous lookups across all policy zones to be performed very rapidly. 来自所有策略区的策略信息一起存储在一个特殊的数据结构中，允许非常快速地同时执行跨所有策略区的查找。 Looking up a policy rule is proportional to the logarithm of the number of rules in the largest single policy zone. 查找策略规则与最大单个策略区中规则数的对数成正比。

6.9.8. Practical Tips for DNS Firewalls and DNS RPZ 6.9.8. DNS 防火墙和 DNS RPZ 的实用技巧

Administrators who subscribe to an externally published DNS policy zone and who have a large number of internal recursive name servers should create an internal name server called a “distribution master” (DM). 订阅外部发布的 DNS 策略区域并拥有大量内部递归名称服务器的管理员应该创建一个称为“分发主机”(DM) 的内部名称服务器。 The DM is a secondary (stealth secondary) name server from the publisher’s point of view; that is, the DM is fetching zone content from the external server. The DM is also a primary name server from the internal recursive name servers’ point of view: they fetch zone content from the DM. 从发布者的角度来看，DM 是二级（隐形二级）名称服务器；也就是说，DM 正在从外部服务器获取区域内容。从内部递归名称服务器的角度来看，DM 也是主要名称服务器：它们从 DM 获取区域内容。 In this configuration the DM is acting as a gateway between the external publisher and the internal subscribers. 在此配置中，DM 充当外部发布者和内部订阅者之间的网关。

The primary server must know the unicast listener address of every subscribing recursive server, and must enumerate all of these addresses as destinations for real time zone change notification (as described in RFC 1996). So if an enterprise-wide RPZ is called “rpz.example.com” and if the unicast listener addresses of four of the subscribing recursive name servers are 192.0.200.1, 192.0.201.1, 192.0.202.1, and 192.0.203.1, the primary server’s configuration looks like this: 主服务器必须知道每个订阅递归服务器的单播侦听器地址，并且必须枚举所有这些地址作为实时时区更改通知的目的地（如 RFC 1996 中所述）。因此，如果一个企业范围的 RPZ 称为“rpz.example.com”，并且如果四个订阅递归名称服务器的单播侦听器地址是 192.0.200.1、192.0.201.1、192.0.202.1 和 192.0.203.1，则主服务器的配置如下所示：

zone "rpz.example.com" {
     type primary;
     file "primary/rpz.example.com";
     notify explicit;
     also-notify { 192.0.200.1;
                   192.0.201.1;
                   192.0.202.1;
                   192.0.203.1; };
     allow-transfer { 192.0.200.1;
                      192.0.201.1;
                      192.0.202.1;
                      192.0.203.1; };
     allow-query { localhost; };
};

Each recursive DNS server that subscribes to the policy zone must be configured as a secondary server for the zone, and must also be configured to use the policy zone for local response policy. 每个订阅策略区的递归 DNS 服务器都必须配置为该区的辅助服务器，并且还必须配置为使用策略区进行本地响应策略。 To subscribe a recursive name server to a response policy zone where the unicast listener address of the primary server is 192.0.220.2, the server’s configuration should look like this: 要将递归名称服务器订阅到主服务器的单播侦听器地址为 192.0.220.2 的响应策略区域，服务器的配置应如下所示：

options {
     // ...
     response-policy {
          zone "rpz.example.com";
     };
     // ...
};

zone "rpz.example.com";
     type secondary;
     primaries { 192.0.222.2; };
     file "secondary/rpz.example.com";
     allow-query { localhost; };
     allow-transfer { none; };
};

Note that queries are restricted to “localhost,” since query access is never used by DNS RPZ itself, but may be useful to DNS operators for use in debugging. Transfers should be disallowed to prevent policy information leaks. 请注意，查询仅限于“本地主机”，因为查询访问从未被 DNS RPZ 本身使用，但可能对 DNS 操作员用于调试很有用。应禁止转移，以防止政策信息泄露。

If an organization’s business continuity depends on full connectivity with another company whose ISP also serves some criminal or abusive customers, it’s possible that one or more external RPZ providers – that is, security feed vendors – may eventually add some RPZ rules that could hurt a company’s connectivity to its business partner. 如果一个组织的业务连续性取决于与另一家公司的完全连接，而另一家公司的 ISP 也为一些犯罪或滥用客户提供服务，那么一个或多个外部 RPZ 提供商（即安全源供应商）可能最终会添加一些 RPZ 规则，这可能会损害公司的与其业务合作伙伴的连接。 Users can protect themselves from this risk by using an internal RPZ in addition to any external RPZs, and by putting into their internal RPZ some “pass-through” rules to prevent any policy action from affecting a DNS response that involves a business partner. 用户可以通过使用内部 RPZ 和任何外部 RPZ 来保护自己免受这种风险，并通过在其内部 RPZ 中放入一些“传递”规则来防止任何策略操作影响涉及业务合作伙伴的 DNS 响应。

A recursive DNS server can be connected to more than one RPZ, and these are searched in order. Therefore, to protect a network from dangerous policies which may someday appear in external RPZ zones, administrators should list the internal RPZ zones first. 一个递归 DNS 服务器可以连接到多个 RPZ，这些是按顺序搜索的。因此，为了保护网络免受有朝一日可能出现在外部 RPZ 区域中的危险策略的影响，管理员应该首先列出内部 RPZ 区域。

options {
     // ...
     response-policy {
          zone "rpz.example.com";
          zone "rpz.security-vendor-1.com";
          zone "rpz.security-vendor-2.com";
     };
     // ...
};

Within an internal RPZ, there need to be rules describing the network assets of business partners whose communications need to be protected. Although it is not generally possible to know what domain names they use, administrators will be aware of what address space they have and perhaps what name server names they use. 在内部 RPZ 中，需要有一些规则来描述其通信需要受到保护的业务合作伙伴的网络资产。虽然通常不可能知道他们使用什么域名，但管理员会知道他们有什么地址空间，也许他们使用什么名称服务器名称。

$ORIGIN rpz.example.com.
8.0.0.0.10.rpz-ip                CNAME   rpz-passthru.
16.0.0.45.128.rpz-nsip           CNAME   rpz-passthru.
ns.partner1.com.rpz-nsdname      CNAME   rpz-passthru.
ns.partner2.com.rpz-nsdname      CNAME   rpz-passthru.

Here, we know that answers in address block 10.0.0.0/8 indicate a business partner, as well as answers involving any name server whose address is in the 128.45.0.0/16 address block, and answers involving the name servers whose names are ns.partner1.com or ns.partner2.com. 在这里，我们知道地址块 10.0.0.0/8 中的答案表示业务合作伙伴，以及涉及地址在 128.45.0.0/16 地址块中的任何名称服务器的答案，以及名称为 ns 的名称服务器的答案.partner1.com 或 ns.partner2.com。

The above example demonstrates that when matching by answer IP address (the .rpz-ip owner), or by name server IP address (the .rpz-nsip owner) or by name server domain name (the .rpz-nsdname owner), the special RPZ marker (.rpz-ip, .rpz-nsip, or .rpz-nsdname) does not appear as part of the CNAME target name. 上面的示例演示了当通过应答 IP 地址（.rpz-ip 所有者）或名称服务器 IP 地址（.rpz-nsip 所有者）或名称服务器域名（.rpz-nsdname 所有者）进行匹配时，特殊 RPZ 标记（.rpz-ip、.rpz-nsip 或 .rpz-nsdname）不会作为 CNAME 目标名称的一部分出现。

By triggering these rules using the known network assets of a partner, and using the “pass-through” policy action, no later RPZ processing (which in the above example refers to the “rpz.security-vendor-1.com” and “rpz.security-vendor-2.com” policy zones) will have any effect on DNS responses for partner assets. 通过使用合作伙伴的已知网络资产触发这些规则，并使用“传递”策略操作，以后的 RPZ 处理（在上面的示例中指的是“rpz.security-vendor-1.com”和“ rpz.security-vendor-2.com”策略区域）将对合作伙伴资产的 DNS 响应产生任何影响。

6.9.9. Creating a Simple Walled Garden Triggered by IP Address 6.9.9.创建一个由 IP 地址触发的简单围墙花园 

It may be the case that the only thing known about an attacker is the IP address block they are using for their “phishing” web servers. 可能的情况是，关于攻击者的唯一信息就是他们用于“网络钓鱼”Web 服务器的 IP 地址块。 If the domain names and name servers they use are unknown, but it is known that every one of their “phishing” web servers is within a small block of IP addresses, a response can be triggered on all answers that would include records in this address range, using RPZ rules that look like the following example: 如果他们使用的域名和名称服务器未知，但已知他们的每个“网络钓鱼”Web 服务器都在一小块 IP 地址内，则可以触发对所有包含该地址记录的答案的响应范围，使用类似于以下示例的 RPZ 规则：

$ORIGIN rpz.example.com.
22.0.212.94.109.rpz-ip          CNAME   drop.garden.example.com.
*.212.94.109.in-addr.arpa       CNAME   .
*.213.94.109.in-addr.arpa       CNAME   .
*.214.94.109.in-addr.arpa       CNAME   .
*.215.94.109.in-addr.arpa       CNAME   .

Here, if a truthful answer would include an A (address) RR (resource record) whose value were within the 109.94.212.0/22 address block, then a synthetic answer is sent instead of the truthful answer. Assuming the query is for www.malicious.net, the synthetic answer is: 在这里，如果一个真实的答案将包括一个 A（地址）RR（资源记录），其值在 109.94.212.0/22 地址块内，那么将发送一个合成答案而不是真实答案。假设查询是针对 www.malicious.net 的，综合答案是：

www.malicious.net.              CNAME   drop.garden.example.com.
drop.garden.example.com.        A       192.168.7.89

This assumes that drop.garden.example.com has been created as real DNS content, outside of the RPZ: 这假设 drop.garden.example.com 已被创建为 RPZ 之外的真实 DNS 内容：

$ORIGIN example.com.
drop.garden                     A       192.168.7.89

In this example, there is no “” in the CNAME target name, so the original query name will not be present in the walled garden web server’s log file. This is an undesirable loss of information, and is shown here for example purposes only. 在此示例中，CNAME 目标名称中没有“”，因此原始查询名称不会出现在围墙花园 Web 服务器的日志文件中。这是一种不受欢迎的信息丢失，此处显示仅用于示例目的。

The above example RPZ rules would also affect address-to-name (also known as “reverse DNS”) lookups for the unwanted addresses. 上面的示例 RPZ 规则还会影响地址到名称（也称为“反向 DNS”）对不需要地址的查找。 If a mail or web server receives a connection from an address in the example’s 109.94.212.0/22 address block, it will perform a PTR record lookup to find the domain name associated with that IP address. 如果邮件或 Web 服务器从示例的 109.94.212.0/22 地址块中的地址接收到连接，它将执行 PTR 记录查找以查找与该 IP 地址关联的域名。

This kind of address-to-name translation is usually used for diagnostic or logging purposes, but it is also common for email servers to reject any email from IP addresses which have no address-to-name translation. 这种地址到名称的转换通常用于诊断或记录目的，但电子邮件服务器拒绝来自没有地址到名称转换的 IP 地址的任何电子邮件也很常见。 Most mail from such IP addresses is spam, so the lack of a PTR record here has some predictive value. 大多数来自此类 IP 地址的邮件都是垃圾邮件，因此此处缺少 PTR 记录具有一定的预测价值。 By using the “force name-does-not-exist” policy trigger on all lookups in the PTR name space associated with an address block, DNS administrators can give their servers a hint that these IP addresses are probably sending junk. 通过对与地址块关联的 PTR 名称空间中的所有查找使用“强制名称不存在”策略触发器，DNS 管理员可以向他们的服务器提示这些 IP 地址可能正在发送垃圾邮件。

6.9.10. A Known Inconsistency in DNS RPZ’s NSDNAME and NSIP Rules 6.9.10。 DNS RPZ 的 NSDNAME 和 NSIP 规则中已知的不一致 

Response Policy Zones define several possible triggers for each rule, and among these two are known to produce inconsistent results. This is not a bug; rather, it relates to inconsistencies in the DNS delegation model. Response Policy Zones 为每个规则定义了几个可能的触发器，并且已知这两个触发器会产生不一致的结果。这不是错误；相反，它与 DNS 授权模型中的不一致有关。

6.9.10.1. DNS Delegation 6.9.10.1。 DNS 授权 

In DNS authority data, an NS RRset that is not at the apex of a DNS zone creates a sub-zone. That sub-zone’s data is separate from the current (or “parent”) zone, and it can have different authoritative name servers than the current zone. 在 DNS 权威数据中，不在 DNS 区域顶点的 NS RRset 创建一个子区域。该子区域的数据与当前（或“父”）区域分开，并且它可以具有与当前区域不同的权威名称服务器。 In this way, the root zone leads to COM, NET, ORG, and so on, each of which have their own name servers and their own way of managing their authoritative data. 通过这种方式，根区域导致 COM、NET、ORG 等，它们中的每一个都有自己的名称服务器和管理其权威数据的方式。 Similarly, ORG has delegations to ISC.ORG and to millions of other “dot-ORG” zones, each of which can have its own set of authoritative name servers. 同样，ORG 拥有对 ISC.ORG 和数百万其他“.ORG”区域的授权，每个区域都可以拥有自己的一组权威名称服务器。 In the parlance of the protocol, these NS RRsets below the apex of a zone are called “delegation points.” An NS RRset at a delegation point contains a list of authoritative servers to which the parent zone is delegating authority for all names at or below the delegation point. 按照协议的说法，区域顶点以下的这些 NS RRset 称为“委派点”。委托点处的 NS RRset 包含授权服务器列表，父区域将委托点处或以下的所有名称委托给这些服务器。

At the apex of every zone there is also an NS RRset. Ideally, this so-called “apex NS RRset” should be identical to the “delegation point NS RRset” in the parent zone, but this ideal is not always achieved. 在每个区域的顶点也有一个 NS RRset。理想情况下，这个所谓的“顶点 NS RRset”应该与父区域中的“委托点 NS RRset”相同，但这种理想并不总是能够实现。 In the real DNS, it’s almost always easier for a zone administrator to update one of these NS RRsets than the other, so that one will be correct and the other out of date. 在真实的 DNS 中，区域管理员几乎总是更容易更新这些 NS RRsets 中的一个而不是另一个，因此一个是正确的而另一个是过时的。 This inconsistency is so common that it’s been necessarily rendered harmless: domains that are inconsistent in this way are less reliable and perhaps slower, but they still function as long as there is some overlap between each of the NS RRsets and the truth. 这种不一致是如此普遍，以至于它必须变得无害：以这种方式不一致的域不太可靠，而且可能更慢，但只要每个 NS RRsets 和真相之间存在一些重叠，它们仍然可以正常工作。 (“Truth” in this case refers to the actual set of name servers that are authoritative for the zone.) （本例中的“真实”是指对该区域具有权威性的实际名称服务器集。）

6.9.10.2. A Quick Review of DNS Iteration 6.9.10.2。 DNS 迭代快速回顾 

In DNS recursive name servers, an incoming query that cannot be answered from the local cache is sent to the closest known delegation point for the query name. 在 DNS 递归名称服务器中，无法从本地缓存回答的传入查询将发送到查询名称的最近的已知委托点。 For example, if a server is looking up XYZZY.ISC.ORG and it the name servers for ISC.ORG, then it sends the query to those servers directly; however, if it has never heard of ISC.ORG before, it must first send the query to the name servers for ORG (or perhaps even to the root zone that is the parent of ORG). 例如，如果服务器正在查找 XYZZY.ISC.ORG 并且它是 ISC.ORG 的名称服务器，那么它将查询直接发送到这些服务器；但是，如果它以前从未听说过 ISC.ORG，它必须首先将查询发送到 ORG 的名称服务器（或者甚至可能发送到作为 ORG 父级的根区域）。

When it asks one of the parent name servers, that server will not have an answer, so it sends a “referral” consisting only of the “delegation point NS RRset.” Once the server receives this referral, it “iterates” by sending the same query again, but this time to name servers for a more specific part of the query name. 当它询问其中一个父名称服务器时，该服务器不会有答案，因此它会发送仅包含“委派点 NS RRset”的“推荐”。一旦服务器收到这个推荐，它就会通过再次发送相同的查询来“迭代”，但这次是为查询名称的更具体部分命名服务器。 Eventually this iteration terminates, usually by getting an answer or a “name error” (NXDOMAIN) from the query name’s authoritative server, or by encountering some type of server failure. 最终此迭代终止，通常是通过从查询名称的权威服务器获得答案或“名称错误”（NXDOMAIN），或者遇到某种类型的服务器故障。

When an authoritative server for the query name sends an answer, it has the option of including a copy of the zone’s apex NS RRset. 当查询名称的权威服务器发送答案时，它可以选择包括区域的顶点 NS RRset 的副本。 If this occurs, the recursive name server caches this NS RRset, replacing the delegation point NS RRset that it had received during the iteration process. 如果发生这种情况，递归名称服务器缓存这个 NS RRset，替换它在迭代过程中收到的委托点 NS RRset。 In the parlance of the DNS, the delegation point NS RRset is “glue,” meaning non-authoritative data, or more of a hint than a real truth. 用 DNS 的说法，委托点 NS RRset 是“胶水”，意思是非权威数据，或者更多的是暗示而不是真实的事实。 On the other hand, the apex NS RRset is authoritative data, coming as it does from the zone itself, and it is considered more credible than the “glue.” For this reason, it’s a little bit more important that the apex NS RRset be correct than that the delegation point NS RRset be correct, since the former will quickly replace the latter, and will be used more often for a longer total period of time. 另一方面，顶点 NS RRset 是权威数据，因为它来自区域本身，被认为比“胶水”更可信。出于这个原因，顶点 NS RRset 的正确性比委托点 NS RRset 的正确性更重要一点，因为前者会很快取代后者，并且会更频繁地使用更长的总时间。

Importantly, the authoritative name server need not include its apex NS RRset in any answers, and recursive name servers do not ordinarily query directly for this RRset. 重要的是，权威名称服务器不需要在任何答案中包含其顶点 NS RRset，并且递归名称服务器通常不会直接查询此 RRset。 Therefore it is possible for the apex NS RRset to be completely wrong without any operational ill-effects, since the wrong data need not be exposed. 因此，顶点 NS RRset 有可能在没有任何操作不良影响的情况下完全错误，因为不需要公开错误的数据。 Of course, if a query comes in for this NS RRset, most recursive name servers will forward the query to the zone’s authority servers, since it’s bad form to return “glue” data when asked a specific question. 当然，如果针对此 NS RRset 进行查询，大多数递归名称服务器会将查询转发到区域的授权服务器，因为在询问特定问题时返回“胶水”数据是一种不好的形式。 In these corner cases, bad apex NS RRset data can cause a zone to become unreachable unpredictably, according to what other queries the recursive name server has processed. 在这些极端情况下，根据递归名称服务器处理的其他查询，错误的顶点 NS RRset 数据可能导致区域不可预测地变得不可访问。

There is another kind of “glue,” for name servers whose names are below delegation points. If ORG delegates ISC.ORG to NS-EXT.ISC.ORG, the ORG server needs to know an address for NS-EXT.ISC.ORG and return this address as part of the delegation response. 对于名称低于授权点的名称服务器，还有另一种“胶水”。如果 ORG 将 ISC.ORG 委托给 NS-EXT.ISC.ORG，则 ORG 服务器需要知道 NS-EXT.ISC.ORG 的地址并将该地址作为委托响应的一部分返回。 However, the name-to-address binding for this name server is only authoritative inside the ISC.ORG zone; therefore, the A or AAAA RRset given out with the delegation is non-authoritative “glue,” which is replaced by an authoritative RRset if one is seen. 但是，此名称服务器的名称到地址的绑定仅在 ISC.ORG 区域内具有权威性；因此，与授权一起给出的 A 或 AAAA RRset 是非权威的“胶水”，如果看到的话，它会被权威的 RRset 取代。 As with apex NS RRsets, the real A or AAAA RRset is not automatically queried for by the recursive name server, but is queried for if an incoming query asks for this RRset. 与顶点 NS 资源记录集一样，递归名称服务器不会自动查询真正的 A 或 AAAA 资源记录集，但如果传入查询要求此资源记录集，则会查询。

6.9.10.3. Enter RPZ 6.9.10.3。输入 RZ 

RPZ has two trigger types that are intended to allow policy zone authors to target entire groups of domains based on those domains all being served by the same DNS servers: NSDNAME and NSIP. RPZ 有两种触发器类型，旨在允许策略区作者根据所有由相同 DNS 服务器提供服务的域来定位整个域组：NSDNAME 和 NSIP。 The NSDNAME and NSIP rules are matched against the name and IP address (respectively) of the nameservers of the zone the answer is in, and all of its parent zones. In its default configuration, BIND actively fetches any missing NS RRsets and address records. NSDNAME 和 NSIP 规则与答案所在区域及其所有父区域的名称服务器的名称和 IP 地址（分别）相匹配。在其默认配置中，BIND 主动获取任何丢失的 NS 资源记录集和地址记录。 If, in the process of attempting to resolve the names of all of these delegated server names, BIND receives a SERVFAIL response for any of the queries, then it aborts the policy rule evaluation and returns SERVFAIL for the query. 如果在尝试解析所有这些委托服务器名称的过程中，BIND 收到任何查询的 SERVFAIL 响应，那么它会中止策略规则评估并为查询返回 SERVFAIL。 This is technically neither a match nor a non-match of the rule. 这在技术上既不是规则的匹配也不是规则的不匹配。

Every “.” in a fully qualified domain name (FQDN) represents a potential delegation point. When BIND goes searching for parent zone NS RRsets (and, in the case of NSIP, their accompanying address records), it has to check every possible delegation point. 每一个 ”。”完全限定域名 (FQDN) 中的 代表潜在的委派点。当 BIND 开始搜索父区域 NS RRsets（以及，在 NSIP 的情况下，它们的伴随地址记录）时，它必须检查每个可能的委托点。 This can become a problem for some specialized pseudo-domains, such as some domain name and network reputation systems, that have many “.” characters in the names. 对于一些专门的伪域来说，这可能会成为一个问题，例如一些域名和网络信誉系统，它们有很多“.”。名称中的字符。 It is further complicated if that system also has non-compliant DNS servers that silently drop queries for NS and SOA records. 如果该系统还具有不合规的 DNS 服务器，这些服务器会静默地丢弃对 NS 和 SOA 记录的查询，则情况会更加复杂。 This forces BIND to wait for those queries to time out before it can finish evaluating the policy rule, even if this takes longer than a reasonable client typically waits for an answer (delays of over 60 seconds have been observed). 这会强制 BIND 等待这些查询超时，然后才能完成对策略规则的评估，即使这花费的时间比合理的客户端通常等待答案的时间更长（已观察到超过 60 秒的延迟）。

While both of these cases do involve configurations and/or servers that are technically “broken,” they may still “work” outside of RPZ NSIP and NSDNAME rules because of redundancy and iteration optimizations. 虽然这两种情况确实涉及技术上“损坏”的配置和/或服务器，但由于冗余和迭代优化，它们仍可能在 RPZ NSIP 和 NSDNAME 规则之外“工作”。

There are two RPZ options, nsip-wait-recurse and nsdname-wait-recurse, that alter BIND’s behavior by allowing it to use only those records that already exist in the cache when evaluating NSIP and NSDNAME rules, respectively. 有两个 RPZ 选项， nsip-wait-recurse 和 nsdname-wait-recurse ，它们分别允许 BIND 在评估 NSIP 和 NSDNAME 规则时仅使用那些已经存在于缓存中的记录，从而改变 BIND 的行为。

Therefore NSDNAME and NSIP rules are unreliable. The rules may be matched against either the apex NS RRset or the “glue” NS RRset, each with their associated addresses (that also might or might not be “glue”). 因此 NSDNAME 和 NSIP 规则是不可靠的。这些规则可以与顶点 NS RRset 或“胶水”NS RRset 匹配，每个规则都有其关联的地址（也可能是也可能不是“胶水”）。 It’s in the administrator’s interests to discover both the delegation name server names and addresses, and the apex name server names and authoritative address records, to ensure correct use of NS and NSIP triggers in RPZ. 发现委托名称服务器名称和地址以及顶级名称服务器名称和权威地址记录符合管理员的利益，以确保在 RPZ 中正确使用 NS 和 NSIP 触发器。 Even then, there may be collateral damage to completely unrelated domains that otherwise “work,” just by having NSIP and NSDNAME rules. 即使那样，仅通过具有 NSIP 和 NSDNAME 规则就可以“工作”的完全不相关的域可能会受到附带损害。

6.9.11. Example: Using RPZ to Disable Mozilla DoH-by-Default 6.9.11。示例：使用 RPZ 默认禁用 Mozilla DoH 

Mozilla announced in September 2019 that they would enable DNS-over-HTTPS (DoH) for all US-based users of the Firefox browser, sending all their DNS queries to predefined DoH providers (Cloudflare’s 1.1.1.1 service in particular). Mozilla 于 2019 年 9 月宣布，他们将为 Firefox 浏览器的所有美国用户启用 DNS-over-HTTPS (DoH)，将他们的所有 DNS 查询发送到预定义的 DoH 提供商（尤其是 Cloudflare 的 1.1.1.1 服务）。 This is a concern for some network administrators who do not want their users’ DNS queries to be rerouted unexpectedly. However, Mozilla provides a mechanism to disable the DoH-by-default setting: if the Mozilla-owned domain use-application-dns.net returns an NXDOMAIN response code, Firefox will not use DoH. 对于一些不希望用户的 DNS 查询意外重新路由的网络管理员来说，这是一个问题。但是，Mozilla 提供了一种机制来禁用 DoH-by-default 设置：如果 Mozilla 拥有的域 use-application-dns.net 返回 NXDOMAIN 响应代码，Firefox 将不会使用 DoH。

To accomplish this using RPZ: 要使用 RPZ 完成此操作：

1. Create a polizy zone file called mozilla.rpz.db configured so that NXDOMAIN will be returned for any query to use-application-dns.net: 创建一个名为 mozilla.rpz.db 的 policy 区域文件，配置后 NXDOMAIN 将返回给 use-application-dns.net 的任何查询：

$TTL  604800
$ORIGIN       mozilla.rpz.
@     IN      SOA     localhost. root.localhost. 1 604800 86400 2419200 604800
@     IN      NS      localhost.
use-application-dns.net CNAME .

1. Add the zone into the BIND configuration (usually named.conf): 将区域添加到 BIND 配置中（通常是 named.conf ）：

zone mozilla.rpz {
    type primary;
    file "/<PATH_TO>/mozilla.rpz.db";
    allow-query { localhost; };
};

1. Enable use of the Response Policy Zone for all incoming queries by adding the response-policy directive into the options {} section: 通过将 response-policy 指令添加到 options {} 部分，为所有传入查询启用响应策略区域：

options {
      response-policy { zone mozilla.rpz; } break-dnssec yes;
};

1. Reload the configuration and test whether the Response Policy Zone that was just added is in effect: 重新加载配置，测试刚刚添加的Response Policy Zone是否生效：

# rndc reload
# dig IN A use-application-dns.net @<IP_ADDRESS_OF_YOUR_RESOLVER>
# dig IN AAAA use-application-dns.net @<IP_ADDRESS_OF_YOUR_RESOLVER>

The response should return NXDOMAIN instead of the list of IP addresses, and the BIND 9 log should contain lines like this: 响应应返回 NXDOMAIN 而不是 IP 地址列表，并且 BIND 9 日志应包含如下行：

09-Sep-2019 18:50:49.439 client @0x7faf8e004a00 ::1#54175 (use-application-dns.net): rpz QNAME NXDOMAIN rewrite use-application-dns.net/AAAA/IN via use-application-dns.net.mozilla.rpz
09-Sep-2019 18:50:49.439 client @0x7faf8e007800 127.0.0.1#62915 (use-application-dns.net): rpz QNAME NXDOMAIN rewrite use-application-dns.net/AAAA/IN via use-application-dns.net.mozilla.rpz

Note that this is the simplest possible configuration; specific configurations may be different, especially for administrators who are already using other response policy zones, or whose servers are configured with multiple views. 请注意，这是最简单的配置；具体配置可能会有所不同，特别是对于已经在使用其他响应策略区域的管理员，或者其服务器配置了多个视图的管理员。