第六章：高级配置6.1. 动态更新6.1.1. 日志文件6.2. 通知6.3. 增量区域转移(IXFR)6.4. 拆分DNS6.4.1. 拆分DNS设置示例6.5. BIND 9中的IPv6支持6.5.1. 使用AAAA记录查找地址6.5.2. 使用Nibble格式的地址到名称查找6.6. 动态可加载区域 (DLZ)6.6.1. 配置 DLZ6.6.2. DLZ模块示例6.7. 动态数据库 (DynDB)6.7.1. 配置 DynDB6.7.2. DynDB模块示例6.8. 目录区域6.8.1. 操作原理6.8.2. 配置目录区域6.8.3. 目录区域格式6.8.4. 目录区域自定义特性6.8.5. 所有权变更 (coo)6.9. DNS防火墙和响应策略区域6.9.1. 为什么使用 DNS 防火墙?6.9.2. DNS防火墙可以做什么?6.9.3. 创建和维护RPZ规则集6.9.4. DNS RPZ的限制6.9.5. DNS 防火墙使用示例6.9.5.1. DNS RPZ值的真实示例6.9.6. 保持防火墙策略更新6.9.7. 使用多个RPZ时的性能和可扩展性6.9.8. DNS防火墙和DNS RPZ实用技巧6.9.9. 创建由IP地址触发的简单围墙花园6.9.10. DNS RPZ的NSDNAME和NSIP规则存在已知的不一致6.9.10.1. DNS委派6.9.10.2. DNS迭代快速回顾6.9.10.3. 进入 RPZ6.9.11. 示例：使用RPZ禁用Mozilla DoH-by-Default
动态更新是一种通过向主服务器发送特殊形式的DNS消息来添加、替换或删除记录的方法。 RFC 2136 中规定了这些消息的格式和含义。
通过在 zone 语句中包含 allow-update 或 update-policy 子句来启用动态更新。
如果区域的 update-policy 设置为 local ，则允许对启动时由 named 生成的密钥 local-ddns 进行区域更新。有关更多详细信息，请参阅动态更新策略( Dynamic Update Policies )。
使用Kerberos签名请求的动态更新可以使用TKEY/GSS协议进行，可以通过设置 tkey-gssapi-keytab 选项或同时设置 tkey-gssapi-credential 和 tkey-domain 选项。启用后，使用Kerberos主体作为请求的签名者，将Kerberos签名的请求与区域的更新策略进行匹配。
安全区域（使用DNSSEC的区域）的更新遵循 RFC 3007 ：服务器使用在线区域密钥自动重新生成受更新影响的RRSIG、NSEC和NSEC3记录。更新授权基于事务签名和明确的服务器策略。
使用动态更新对区域所做的所有更改都存储在区域的日志文件中。当第一次动态更新发生时，服务器会自动创建此文件。日志文件的名称是通过在相应区域文件的名称后附加扩展名 .jnl 形成的，除非被特别覆盖。日志文件为二进制格式，不应手动编辑。
服务器偶尔也会将更新区域的完整内容写入（“转储”）到其区域文件中。这不会在每次动态更新后立即完成，因为当一个大区域频繁更新时，这会太慢。相反，转储延迟了15分钟，允许进行额外的更新。在转储过程中，会创建扩展名为 .jnw 和 .jbk 的临时文件；在一般情况下，这些在转储完成后会被删除，可以安全地忽略。
当服务器在关闭或崩溃后重新启动时，它会重放日志文件，将上次区域转储后发生的任何更新合并到区域中。
由传入的增量区域转移引起的更改也以类似的方式记录。
动态区域的区域文件通常不能手动编辑，因为它们不能保证包含最新的动态更改；这些只在日志文件中。确保动态区域的区域文件是最新的唯一方法是运行 rndc stop 。
要手动更改动态区域，请执行以下步骤：首先，使用 rndc freeze zone 禁用对区域的动态更新。这将使用其 .jnl 文件中存储的更改更新区域文件。然后，编辑分区文件。最后，运行 rndc thaw zone 以重新加载更改的区域并重新启用动态更新。
rndc sync zone 根据日志文件的更改更新区域文件，而不停止动态更新；这可能有助于查看当前区域状态。要在更新区域文件后删除 .jnl 文件，请使用 rndc sync clean 。
DNS NOTIFY是一种机制，允许主服务器将区域数据的更改通知其辅助服务器。响应来自主服务器的NOTIFY消息，辅助服务器检查其区域版本是否为当前版本，如果不是，则启动区域传输。
有关DNS NOTIFY的更多信息，请参阅 notify和 :namedconf:refalso-notify 语句的描述。NOTIFY协议在 RFC 1996 中指定。
注：
由于辅助区域也可以是其他辅助区域的主区域，默认情况下，named 区域会为其加载的每个区域发送NOTIFY消息。
增量区域传输（incremental zone transfer —— IXFR）协议是辅助服务器仅传输更改数据的一种方式，而不必传输整个区域。IXFR协议在 RFC 1995 中进行了规定。
当充当主服务器时，BIND 9支持IXFR用于那些有必要的更改历史信息可用的区域。这些区域包括由动态更新维护的主要区域和由IXFR获得数据的次要区域。对于手动维护的主区域和通过执行完整区域传输（AXFR）获得的辅助区域，只有当 ixfr-from-differences 设置为 yes 时，才支持IXFR。
当充当辅助服务器时，BIND 9会尝试使用IXFR，除非它被明确禁用。有关禁用IXFR的更多信息，请参阅 server 语句的 request-ixfr 子句的描述。
当辅助服务器通过AXFR接收区域时，它会创建区域数据库的新副本，然后将其交换到位；在加载过程中，查询继续从旧数据库提供，没有干扰。然而，当通过IXFR接收区域时，更改会应用于正在运行的区域，这可能会降低传输过程中的查询性能。如果接收IXFR请求的服务器确定响应大小与AXFR响应大小相似，则可能希望发送AXFR。可以使用 max-ixfr-ratio 选项配置做出此决定的阈值。
为内部和外部解析器设置DNS空间的不同视图通常被称为 split DNS (拆分DNS)设置。组织可能希望以这种方式设置DNS有几个原因。
使用拆分DNS的一个常见原因是对互联网上的“外部”客户端隐藏“内部”DNS信息。关于这是否真的有用，存在一些争论。内部DNS信息以多种方式泄露（例如通过电子邮件头），最精明的“攻击者”可以使用其他方式找到他们需要的信息。然而，由于列出外部客户端无法访问的内部服务器的地址可能会导致连接延迟和其他烦恼，因此组织可能会选择使用拆分DNS向外界呈现一致的自身视图。
设置拆分DNS系统的另一个常见原因是允许过滤器后面或RFC 1918空间（RFC 1918中记录的保留IP空间）中的内部网络解析互联网上的DNS。拆分DNS也可用于允许邮件从外部返回到内部网络。
比方说，一家名为 Example, Inc.（Example.com）的公司有几个公司网站，这些网站有一个内部网络，带有保留的互联网协议（IP）空间和一个外部非军事区（DMZ），或网络的“外部”部分，可供公众使用。
Example, Inc.希望其内部客户能够解析外部主机名，并与外部人员交换邮件。该公司还希望其内部解析器能够访问某些仅限内部的区域，而这些区域在内部网络之外根本不可用。
为了实现这一目标，该公司建立了两套名称服务器。一组位于内部网络（在保留的IP空间中），另一组位于堡垒主机上，堡垒主机是DMZ中的“代理”主机，可以与网络两侧通信。
内部服务器被配置为将所有查询（ site1.internal 、site2.internal 、site1.example.com 和 site2.example.com 的查询除外）转发到DMZ中的服务器。这些内部服务器具有 site1.example.com 、site2.example.com 、site1.internal 和 site2.internal 的完整信息集。
为了保护 site1.internal 和 site2.internal 域，必须将内部名称服务器配置为禁止任何外部主机（包括堡垒主机）对这些域的所有查询。
堡垒主机上的外部服务器被配置为服务于 site1.example.com 和 site2.example.com 区域的“public”版本。这可能包括公共服务器的主机记录（ www.example.com 和 ftp.example.com ）和邮件交换（MX）记录（ a.MX.example.com 和 b.MX.example.com）。
此外，公共 site1.example.com 和 site2.example.com 区域应具有特殊的MX记录，其中包含指向堡垒主机的通配符（*）记录。这是必要的，因为外部邮件服务器没有其他方法来确定如何将邮件传递到这些内部主机。使用通配符记录，邮件被传递到堡垒主机，然后堡垒主机可以将其转发到内部主机。
这是一个通配符MX记录的示例：
* IN MX 10 external1.example.com.现在他们代表内部网络中的任何东西接受邮件，堡垒主机需要知道如何将邮件传递给内部主机。堡垒主机上的解析器需要配置为指向内部名称服务器进行DNS解析。
对内部主机名的查询由内部服务器回答，对外部主机名的请求被转发回堡垒主机上的DNS服务器。
为了使所有这些正常工作，内部客户端需要配置为仅查询内部名称服务器的DNS查询。这也可以通过网络上的选择性过滤来实现。
如果一切设置得当，Example,Inc.的内部客户现在能够：
site1.example.com 和 site2.example.com 区域中查找任何主机名。site1.internal 和 site2.internal 域中查找任何主机名。互联网上的主机可以：
site1.example.com 和 site2.example.com 区域中查找任何主机名。site1.example.com 和 site2.example.com 区域中的任何人交换邮件。这是上述设置的示例配置。请注意，这只是配置信息；有关如何配置区域文件的信息，请参阅配置和区域文件。
内部DNS服务器配置：
xacl 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 zonezone "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 zonezone "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; }};外部（堡垒主机）DNS服务器配置：
xxxxxxxxxxacl 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 zonezone "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; }};在堡垒主机上的resolv.conf（或等效文件）中：
xxxxxxxxxxsearch ...nameserver 172.16.72.2nameserver 172.16.72.3nameserver 172.16.72.4BIND 9完全支持所有当前定义的IPv6名称到地址和地址到名称查找形式。它还使用IPv6地址在支持IPv6的系统上运行时进行查询。
对于正向查找，BIND 9仅支持AAAA记录。RFC 3363不推荐使用A6记录，因此BIND 9中删除了对A6记录的客户端支持。然而，权威的BIND 9名称服务器仍然可以正确加载包含A6记录的区域文件，回答A6记录的查询，并接受包含A6记录区域的区域传输。
对于IPv6反向查找，BIND 9支持 ip6.arpa 域中使用的传统“半字节(nibble)”格式，以及旧的、已弃用的 ip6.int 域。旧版本的BIND 9支持“二进制标签(binary label)”（也称为“位串bitstring”）格式，但根据 RFC 3363 ，对二进制标签的支持已被完全删除。BIND 9中的许多应用程序根本不理解二进制标签格式，如果给出错误，则返回错误。特别是，权威的BIND 9名称服务器不会加载包含二进制标签的区域文件。
IPv6 AAAA记录与IPv4 A记录并行，与弃用的A6记录不同，它在单个记录中指定了整个IPv6地址。例如：
xxxxxxxxxx$ORIGIN example.com.host 3600 IN AAAA 2001:db8::1不建议使用 IPv4-in-IPv6 映射地址。如果主机有IPv4地址，请使用A记录，而不是地址为::ffff:192.168.42.1 的AAAA记录。
当以半字节(nibble)格式查找地址时，地址成分只是颠倒过来，就像IPv4和 ip6.arpa. 一样。将附加到结果名称后。例如，以下命令为地址为 2001:db8::1 的主机生成反向名称查找：
xxxxxxxxxx$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. )动态可加载区域（Dynamically Loadable Zones —— DLZ）是BIND 9的扩展，允许直接从外部数据库检索区域数据。没有所需的格式或架构。
有许多贡献的DLZ模块用于几个不同的数据库后端，包括MySQL和LDAP，但它们没有得到积极的维护。
DLZ模块以文本格式向 named 提供数据，然后按 named 将其转换为DNS有线格式。这种转换以及缺乏任何内部缓存，极大地限制了DLZ模块的查询性能。因此，不建议在高容量服务器上使用DLZ。但是，它可以在隐藏的主配置中使用，辅助配置通过AXFR检索区域更新。但是请注意，DLZ没有内置的DNS通知支持；数据库中的区域更改不会自动通知辅助服务器。
dlz
Grammar zone (primary, redirect, secondary): dlz <string>;
Grammar topmost, view:
xxxxxxxxxxdlz <string> { database <string>; search <boolean>;}; // may occur multiple timesBlocks: topmost, view, zone (primary, redirect, secondary)
Tags: zone
在 named.conf 中配置动态可加载区域（Dynamically Loadable Zone —— DLZ）数据库。
DLZ数据库在 named.conf 中配置了 DLZ 语句：
xxxxxxxxxxdlz example {database "dlopen driver.so args";search yes;};
这指定了在回答查询时要搜索的DLZ模块；该模块在driver.so中实现，并在运行时由dlopen DLZ驱动程序加载。可以指定多个 dlz 语句。
search
search <boolean>;指定是否向动态可加载区域（DLZ）模块查询查询名称的答案。
在回答查询时，所有 search 设置为 yes 的DLZ模块都会被查询，以查看它们是否包含查询名称的答案。最佳答案将返回给客户。
上述示例中的 search 选项可以省略，因为 yes 是默认值。
如果 search 设置为 no ，则在收到查询时，不会搜索此DLZ模块以寻找最佳匹配。相反，此DLZ中的区域必须在区域声明中单独指定。这允许用户通常使用标准区域选项语义配置区域，但指定不同的数据库后端来存储区域的数据。例如，要使用DLZ模块实现NXDOMAIN重定向，用于重定向规则的后端存储：
xxxxxxxxxxdlz other { database "dlopen driver.so args"; search no;};zone "." { type redirect; dlz other;};有关DLZ模块实施的指导，请访问[gitlab.isc.org/isc-projects/DLZ modules]中的 example 目录(https://gitlab.isc.org/isc-projects/dlz-modules/-/tree/main/example?ref_type=heads)包含一个基本的动态可链接DLZ模块，即可以在运行时由“dlopen”DLZ驱动程序加载的模块。该示例设置了一个单独的区域，其名称作为dlz语句中的参数传递给模块：
xxxxxxxxxxdlz other { database "dlopen driver.so example.nil";};在上面的示例中，该模块被配置为创建一个区域“example.nil”，该区域可以回答查询和AXFR请求，并接受DDNS更新。在运行时，在任何更新之前，该区域包含一个SOA、NS和位于顶点的单个A记录：
xxxxxxxxxxexample.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示例驱动程序可以检索有关查询客户端的信息，并根据此信息更改其响应。为了演示此功能，示例驱动程序使用查询的源地址响应"source addr.''zonename''>/TXT"查询。但是请注意，此记录不会包含在AXFR或ANY回复中。通常，此功能用于以其他方式更改响应，例如，根据查询来自的网络为特定名称提供不同的地址记录。
API DLZ模块的文档可在[README]中找到(https://gitlab.isc.org/isc-projects/dlz-modules/-/raw/main/example/README). 此存储库还包含头文件dlz_minimal.h，定义了API，并且应该由任何动态可链接的DLZ模块包括。
动态数据库（DynDB）是BIND 9的扩展，它与DLZ（参见动态可加载区域（DLZ））一样，允许从外部数据库检索区域数据。与DLZ不同，DynDB模块提供了一个功能齐全的BIND区域数据库接口。当DLZ将DNS查询转换为实时数据库查找，导致查询性能相对较差，并且由于其有限的API而无法处理DNSSEC签名的数据时，DynDB模块可以从外部数据源预加载内存中的数据库，提供与BIND本机服务的区域相同的性能和功能。
Red Hat已创建支持LDAP的DynDB模块，可从以下网址获得https://pagure.io/bind-dyndb-ldap.
BIND源代码中包含一个用于测试和开发人员指导的示例DynDB模块，位于目录 bin/tests/system/DynDB/driver 中。
dyndb
dyndb <string> <quoted_string> { <unspecified-text> }; // may occur multiple times在 named.conf 中配置DynDB数据库。
DynDB数据库在 named.conf 中配置了 dyndb 语句：
xxxxxxxxxxdyndb example "driver.so" { parameters};文件 driver.so 是一个DynDB模块，用于实现完整的DNS数据库API。可以指定多个 dyndb 语句，以加载不同的驱动程序或同一驱动程序的多个实例。DynDB模块提供的区域将添加到视图的区域表中，并在BIND响应查询时被视为正常的权威区域。区域配置由DynDB模块内部处理。
参数以不透明字符串的形式传递给DynDB模块的初始化例程。配置语法因驱动程序而异。
为了指导DynDB模块的实现，目录 bin/tests/system/DynDB/driver 包含一个基本的DynDB模型。该示例设置了两个区域，其名称作为 dyndb 语句中的参数传递给模块：
xxxxxxxxxxdyndb sample "sample.so" { example.nil. arpa. };在上面的示例中，该模块被配置为创建一个区域“example.nil”，该区域可以回答查询和AXFR请求，并接受DDNS更新。在运行时，在任何更新之前，该区域包含一个SOA、NS和位于顶点的单个A记录：
xxxxxxxxxxexample.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当区域动态更新时，DynDB模块确定更新的RR是否是地址（即类型A或AAAA）；如果是这样，它会自动更新反向区域中的相应PTR记录。请注意，更新不会永久存储；服务器重新启动时，所有更新都会丢失。
“catalog zone" —— 目录区域，是一个特殊的DNS区域，其中包含要服务的其他区域的列表及其配置参数。目录区域中列出的区域称为“member zones” —— 成员区域。当目录区域加载或传输到支持此功能的辅助服务器时，辅助服务器会自动创建成员区域。当目录区域更新时（例如，添加或删除成员区域，或更改其配置参数），这些更改将立即生效。由于目录区域是一个普通的DNS区域，因此可以使用标准的AXFR/IXFR区域传输机制传播这些配置更改。
RFC 9432 中规定了目录区域的格式和行为。
通常，如果一个区域由辅助服务器提供服务，服务器上的 named.conf 文件必须列出该区域，或者必须使用 rndc addzone 添加该区域。在具有大量辅助服务器的环境中，和/或在所服务的区域频繁变化的情况下，在所有辅助服务器上维护一致的区域配置所涉及的开销可能很大。
目录区域是减轻这种管理负担的一种方式：它是一个DNS区域，列出了应由辅助服务器提供服务的成员区域。当辅助服务器接收到目录区域的更新时，它会根据接收到的数据添加、删除或重新配置成员区域。
要使用目录区域，必须首先在配置为使用它的主服务器和辅助服务器上将其设置为普通区域。还必须将其添加到 named.conf 中 options 或 view 语句中的 catalog-zones 列表中。这与将策略区域配置为普通区域并在 response-policy 语句中列出的方式类似。
要使用目录区域功能为新成员区域提供服务，请执行以下操作：
named.conf 或运行 rndc addzone 来完成。rndc reload ，或者使用 nsupdate 更新区域来完成。目录区域的更改使用正常的AXFR/IXFR机制从主目录传播到所有次目录。当辅助服务器接收到目录区域的更新时，它会检测新成员区域的条目，在辅助服务器上创建该区域的实例，并将该实例指向目录区域数据中指定的 primaries 。新创建的成员区域是一个普通的辅助区域，因此BIND会立即从主区域传输区域内容。一旦完成，次要服务器将开始为成员区域提供服务。
从辅助服务器中删除成员区域只需要删除目录区域中的成员区域条目；使用正常的AXFR/IXFR传输机制将对目录区域的更改传播到辅助服务器。辅助服务器在处理更新时注意到成员区域已被删除，停止为该区域提供服务，并将其从配置的区域列表中删除。但是，必须通过编辑配置文件或运行 rndc delzone 来从主服务器中删除成员区域。
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: zone
在 named.conf 中配置目录区域。
目录区域在 named.conf 的 options 或 view 部分使用 catalog-zones 语句进行配置。例如：
xxxxxxxxxxcatalog-zones { zone "catalog.example" default-primaries { 10.53.0.1; } in-memory no zone-directory "catzones" min-update-interval 10;};此语句指定区域 catalog.example 是一个目录区域。必须在同一视图中正确配置此区域。在大多数配置中，它将是一个次要区域。
区域名称后面的选项不是必需的，可以按任何顺序指定。
default-masters
default-primaries 的同义词。default-primaries
此选项定义了目录区域中列出的成员区域的默认主区域，并且可以被目录区域中的选项覆盖。如果不包括此类选项，则成员区域将从此选项中列出的服务器传输其内容。in-memory
如果将此选项设置为 yes ，则会导致成员区域仅存储在内存中。这在功能上相当于在没有 file 选项的情况下配置辅助区域。默认值为 no ；成员区域的内容存储在本地的一个文件中，该文件的名称由视图名称、目录区域名称和成员区域名称自动生成。zone-directory
如果 in-memory 未设置为 yes ，则此选项会导致成员区域区域文件的本地副本存储在指定目录中。默认情况下，将区域文件存储在服务器的工作目录中。假设 zone-directory 中的非绝对路径名相对于工作目录。min-update-interval
此选项设置目录区域更新之间的最小间隔（秒）。如果目录区域的更新（例如，通过IXFR）在最近一次更新后不到 min-update-intervar 秒发生，则在经过此间隔之前不会执行更改。默认值为5秒。目录分区是基于每个视图定义的。在视图中配置非空的 catalog-zones 语句会自动启用该视图的 allow-new-zones 。这意味着 rndc addzone 和 rndc delzone 也适用于支持目录区域的任何视图。
目录区域是常规DNS区域；因此，它必须有一个SOA和至少一个 NS 记录。
还需要一份记录，说明目录区域格式的版本。如果服务器不支持列出的版本号，则该服务器可能无法使用目录区域。
xxxxxxxxxxcatalog.example. IN SOA . . 2016022901 900 600 86400 1catalog.example. IN NS invalid.version.catalog.example. IN TXT "2"请注意，此记录必须具有域名version.catalog-zone-name 。存储在目录区域中的数据由目录区域域之前的域名标签指示。目前BIND支持目录区域架构版本“1”和“2”。
另请注意，目录区域必须有NS记录才能成为有效的DNS区域，建议对NS使用值“invalid”。
通过在目录区域的区域子域中包含PTR资源记录来添加成员区域。记录标签可以是任何唯一的标签。PTR记录的目标是成员区域名称。例如，要添加成员区域 domain.example 和domain2.example ：
xxxxxxxxxx5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN PTR domain.example.uniquelabel.zones.catalog.example. IN PTR domain2.example.标签是标识特定成员区域的自定义属性（见下文）所必需的。此外，可以通过更改其标签来重置区域状态，在这种情况下，BIND将删除成员区域并重新添加。
BIND使用目录区域自定义特性来定义不同的特性，这些特性可以为整个目录区域或单个成员区域全局设置。全局自定义特性覆盖配置文件中的设置，成员区域自定义特性覆盖全局自定义特性。
对于模式的版本“1”，自定义属性必须放置在没有特殊后缀的位置。
对于模式的版本“2”，自定义属性必须放置在“.ext”后缀下。
全局自定义特性设置在目录区域的顶点，例如：
xxxxxxxxxxprimaries.ext.catalog.example. IN AAAA 2001:db8::1BIND目前支持以下自定义属性：
一个简单的 primaries 定义：
xxxxxxxxxxprimaries.ext.catalog.example. IN A 192.0.2.1此自定义属性定义了成员区域的主服务器，可以是A或AAAA记录。如果设置了多个初选，则使用它们的顺序是随机的。
注意：masters 可以用作 primaries 的同义词。
定义了TSIG密钥的 primaries ：
xxxxxxxxxxlabel.primaries.ext.catalog.example. IN A 192.0.2.2label.primaries.ext.catalog.example. IN TXT "tsig_key_name"此自定义属性使用TSIG密钥集为成员区域定义主服务器。TSIG密钥必须在配置文件中配置。label 可以是任何有效的DNS标签。
注意：masters 可以用作 primaries 的同义词。
allow-query 和 allow-transfer ACLs:
xxxxxxxxxxallow-query.ext.catalog.example. IN APL 1:10.0.0.1/24allow-transfer.ext.catalog.example. IN APL !1:10.0.0.1/32 1:10.0.0.0/24这些自定义属性相当于 named.conf 配置文件中区域声明中的 allow-query 和 allow-transfer 选项。ACL按顺序处理；如果不符合任何规则，默认策略是拒绝访问。有关APL RR的语法，请参阅 RFC 3123 。
成员区域特定的自定义属性的定义方式与全局自定义属性相同，但在成员区域子域中：
xxxxxxxxxxprimaries.ext.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN A 192.0.2.2label.primaries.ext.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN AAAA 2001:db8::2label.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/24primaries.ext.uniquelabel.zones.catalog.example. IN A 192.0.2.3为特定区域定义的自定义特性将覆盖目录区域中定义的全局自定义特性。这些反过来会覆盖配置文件中 catalog-zones 语句中定义的全局选项。
请注意，如果为特定区域的自定义属性定义了任何记录，则不会继承该自定义属性的全局记录。例如，如果该区域的 primaries 记录类型为A，但不是AAAA，则它不会从全局自定义属性或配置文件中的全局选项继承AAAA类型的记录。
BIND支持目录区域“所有权变更”（Change of Ownership —— coo）属性。当一个目录区域中存在的同一条目被添加到另一个目录区中时，BIND的默认行为是忽略它，并继续使用它最初存在的目录区为该区域提供服务，除非它从那里被删除，否则它可以被添加到新的目录区中。
使用 coo 属性，可以通过让目录消费者知道允许这样做，将一个区域从一个目录区域优雅地移动到另一个目录区。为此，应使用具有 coo 自定义属性的新记录更新原始目录区域：
xxxxxxxxxxuniquelabel.zones.catalog.example. IN PTR domain2.example.coo.uniquelabel.zones.catalog.example. IN PTR catalog2.example.在这里，catalog.example catalog区域允许标签为“uniquelabel”的成员区域转移到 catalog2.example catalog区域。支持coo属性的目录消费者会注意到，当该区域最终添加到 catalog2.example 目录区域时，目录消费者会将该区域的所有权从catalog.example 更改为 catalog2.sample 。BIND的实现只是从旧目录区域中删除该区域并将其添加回新目录区域，这也意味着刚刚迁移的区域的所有相关状态都将被重置，包括唯一标签相同时。
在确认所有消费者都已收到并成功更改了区域的所有权后，目录区域操作员可以稍后删除具有 coo 自定义属性的记录。
DNS防火墙检查DNS流量，允许一些响应通过，同时阻止其他响应。此检查可以基于几个标准，包括请求的名称、与该名称相关的数据（如IP地址），或对请求的名称具有权威性的名称服务器的名称或IP地址。基于这些标准，DNS防火墙可以配置为丢弃(discard)、修改(modify)或替换(replace)原始响应，使管理员能够更好地控制哪些系统可以访问或从其网络访问。
DNS响应策略区域（Response Policy Zones —— RPZ）是一种DNS防火墙形式，其中防火墙规则在DNS本身中表示，以开放的、供应商中立(vendor-neutral)的格式编码为特殊构造的DNS区域中的记录。
使用DNS区域配置策略允许使用标准DNS区域传输机制将策略从一个服务器共享到另一个服务器。这允许DNS运营商维护自己的防火墙策略，并在内部名称服务器之间轻松共享，或订阅外部防火墙策略，如商业或合作的“威胁源(threat feeds)”，或两者兼而有之。
named 最多可以订阅64个响应策略区域，每个区域都编码一个单独的策略规则集。每个规则都存储在RPZ内的DNS资源记录集中（RRset），由 tigger (触发器)和 action (动作)组成。有五种类型的触发器和六种类型的动作。
DNS RPZ中的响应策略规则可以按如下方式触发：
响应策略操作可以是以下之一：
DNS防火墙最常见的用途是“poison(毒害)”域名、IP地址、名称服务器名称或名称服务器IP地址。中毒通常是通过强制合成“域不存在”（NXDOMAIN）反应来实现的。这意味着，如果管理员维护一个已知的“钓鱼(phishing)”域列表，客户或最终用户只需在递归DNS服务器中添加防火墙策略，每个已知的“钓鱼”域都有一个触发器，并且在每种情况下都会强制执行合成NXDOMAIN响应，就可以访问这些名称。还可以使用数据替换操作，例如用可以显示警告页面的本地web服务器的名称来回答这些已知的“钓鱼”域。这样的网络服务器将被称为“围墙花园(walled garden)”。
注意： 权威名称服务器可以负责许多不同的域。如果使用DNS RPZ来毒害由某个权威名称服务器名称或地址服务的所有域，其影响可能会非常深远。建议用户确保此类权威名称服务器不会同时服务于不应被毒害的域名。
互联网上的犯罪和网络滥用流量通常使用域名系统（DNS），因此针对这些威胁的保护应包括DNS防火墙。DNS防火墙可以选择性地拦截已知网络资产的DNS查询，包括域名、IP地址和名称服务器。拦截可能意味着重写DNS响应，将web浏览器定向到“围墙花园”，或者只是使任何恶意网络资产不可见且无法访问。
防火墙通过将一组规则应用于流量来工作，其中每条规则都由一个触发器(trigger)和一个动作(action)组成。触发器决定了流量流中哪些消息被特殊处理，操作决定了这种特殊处理是什么。对于DNS防火墙，要控制的流量由递归DNS服务器向其最终用户客户端发送的响应组成。一些真实的响应并非对所有客户端都是安全的，因此DNS防火墙中的策略规则允许拦截一些响应并用更安全的内容替换。
在DNS RPZ中，DNS防火墙策略规则集存储在DNS区域中，该区域使用与任何其他DNS区域相同的工具和方法进行维护和同步。如果管理员正在创建和维护自己的DNS策略区域，DNS RPZ的主名称服务器可以是内部服务器，如果导入外部发布的策略区域，则可以是外部名称服务器（如安全供应商的服务器）。DNS防火墙策略的主副本可以是手动编辑或从数据库生成的DNS“区域文件”。还可以使用DNS动态更新（例如，使用“nsupdate”shell级实用程序）间接编辑DNS区域。
DNS RPZ允许防火墙规则以DNS区域格式表示，然后作为DNS数据携带给订阅者。能够处理DNS RPZ的递归DNS服务器使用用于辅助名称服务的相同标准DNS工具和协议来同步这些DNS防火墙规则。然后，DNS策略信息被提升到客户DNS解析器内的DNS控制平面，使该服务器成为DNS防火墙。
产品包括威胁情报提要的安全公司可以使用DNS响应策略区（RPZ）作为向客户交付的渠道。威胁可以表示为已知的恶意IP地址和子网、已知的恶意域名和已知的恶意域服务器。通过将此威胁信息直接输入客户的本地DNS解析器，提供商可以将这些DNS服务器转换为分布式DNS防火墙。
当客户的DNS解析器通过实时订阅连接到威胁情报馈送时，提供商可以在发现恶意网络元素（包括IP地址和子网、域名和名称服务器）时立即保护客户的最终用户免受其攻击。虽然一旦报告，可能需要几天或几周的时间才能“关闭”犯罪和滥用基础设施，但分布式DNS防火墙可以立即响应。
其他分布式TCP/IP防火墙已经上市多年，企业用户现在可以放心地将来自安全供应商的实时威胁情报直接导入防火墙。这种智能可以采用已知的恶意IP地址或子网的形式，也可以采用识别已知恶意电子邮件附件、文件下载或网址（URL）的模式。在某些产品中，还可以根据DNS数据包所携带的名称或地址来阻止它们。
我们经常被问到是否可以使用DNS RPZ来设置重定向到CDN。例如，如果“mydomain.com”是一个具有SOA、NS、MX、TXT记录等的普通域，那么如果有人对“mydomains.com”发送A或AAAA查询，我们可以在权威名称服务器上使用DNS RPZ返回“CNAME mydomain.com.my-cdn-provider.net”吗？
这个建议的问题是，即使使用RPZ，也无法进行仅CNAME的A和AAAA查询。
根本原因是，如果权威服务器使用CNAME进行响应，则进行该查询的递归服务器将缓存响应。此后（当CNAME仍在缓存中时），它假设所查询的名称没有任何非CNAME类型的记录，并将所有其他类型的后续查询直接指向CNAME记录的目标名称。
需要明确的是，这不是对RPZ的限制；它是DNS协议工作方式的函数。在设置CDN时，根本不可能使用“部分”CNAMES来提供帮助，因为这样做会破坏其他功能，如电子邮件路由。
同样，根据DNS协议定义， *.example 记录形式的通配符可能表现得不直观。有关DNS中通配符的详细定义，请参阅 RFC 4592 ，特别是第2节。
以下是DNS防火墙可能有用的一些场景。
一些已知的威胁基于IP地址或子网（IP地址范围）。例如，分析可能表明，“C类”网络中的所有地址都被犯罪团伙用于“钓鱼”网络服务器。使用基于DNS RPZ的DNS防火墙，可以创建防火墙策略，例如“如果DNS查找将导致来自此C类网络的地址，则使用NXDOMAIN指示进行应答。”这个简单的规则将防止客户网络内的任何最终用户能够查找此网络钓鱼攻击中使用的任何域名，而无需事先知道这些名称可能是什么。
其他已知的威胁是基于域名的。分析可以确定某个域名或一组域名正在或即将用于垃圾邮件、网络钓鱼或其他基于互联网的攻击，这些攻击都需要可用的域名。通过在分布式DNS防火墙中添加名称触发规则，提供商可以保护客户的最终用户免受任何攻击，这些攻击要求他们能够查找任何这些恶意名称。名称可以是通配符（例如*.evil.com），如果某些域不像其他域那样恶意，这些通配符可能会有例外（如果*.evil.com是坏的，那么not.evil.com可能是例外）。
随着电子犯罪的增长，电子犯罪专业知识也在增长。许多犯罪团伙现在拥有自己广泛的DNS基础设施，以支持大量域名和各种IP地址资源。分析表明，在许多情况下，犯罪组织唯一真正固定的资产是他们的域名服务器，从本质上讲，它们的移动性略低于其他网络资产。在这种情况下，DNS管理员可以将其DNS防火墙策略锚定在滥用名称服务器名称或名称服务器地址中，从而保护其客户的最终用户免受事先不知道域名或IP地址的威胁。
电子罪犯和数字社会的其他人一样，依赖DNS的完全弹性。通过在DNS级别锁定犯罪资产，我们可以剥夺这些罪犯所需的弹性。分布式DNS防火墙可以利用安全公司的高技能来保护大量最终用户。DNS RPZ作为第一个开放和供应商中立的分布式DNS防火墙，可以成为向客户提供威胁情报的有效方式。
Conficker恶意软件蠕虫(https://en.wikipedia.org/wiki/Conficker) 2008年首次被发现。虽然它不再是一个活跃的威胁，但这里描述的技术可以应用于其他DNS威胁。
Conficker使用域生成算法（domain generation algorithm —— DGA）每天选择多达50000个命令和控制域。创建一个包含如此多域名和每天如此多变化的RPZ是不切实际的。相反，我们可以根据对命令和控制域具有权威性的名称服务器的名称触发RPZ规则，而不是试图在50000个不同的（每日）查询名称中的每一个上触发。由于Conficker域名的知名名称服务器名称从未被非恶意域名使用，因此可以安全地毒害依赖于这些名称服务器的所有查找。以下是一个实现此结果的示例：
xxxxxxxxxx$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.这些CNAME目标名称开头的 * 是特殊的，它会导致原始查询名称被添加到CNAME目标之前。因此，如果用户试图访问Conficker命令和控制域 racaldftn.com.ai （这是2011年10月19日有效的Conficker命令与控制域名），RPZ配置的递归名称服务器将返回以下答案：
xxxxxxxxxxracaldftn.com.ai. CNAME racaldftn.com.ai.walled-garden.example.com.racaldftn.com.ai.walled-garden.example.com. A 192.168.50.3此示例假定还创建了以下DNS内容，该内容不是RPZ区域本身的一部分，而是在另一个域中：
xxxxxxxxxx$ORIGIN walled-garden.example.com.* A 192.168.50.3假设我们正在运行一个监听192.168.50.3的web服务器，无论使用什么统一资源标识符（uniform resource identifier —— URI），该服务器都会始终显示警告消息，上述RPZ配置将指示任何受感染的最终用户的web浏览器连接到一个“server name”，该名称由其原始查找名称（racaldftn.com.ai）和围墙花园域名（walledgarden.example.com）前缀组成。这是将出现在web服务器日志文件中的名称，在该日志文件中具有全名将有助于分析哪些用户感染了什么病毒。
增量区域传输（见RFC 1995）和实时更改通知（见RFC 1996）用于在规则集的发布者主副本和规则集的订阅者工作副本之间同步DNS防火墙规则集，这对整体系统性能至关重要。
如果使用DNS动态更新来维护DNS RPZ规则集，则名称服务器会自动计算增量区域传输到订阅名称服务器时使用的增量流。发送一系列增量数据流（称为“增量区域传输”或IXFR）通常比每次更改时发送完整区域快得多，因此使用一种使这种增量传输成为可能的编辑方法是值得的。
编辑或定期重新生成DNS RPZ规则集并且其主要名称服务器使用BIND的管理员可以启用 ixfr-from-differences 选项，该选项“告诉”主要名称服务器计算每个新区域与先前版本之间的差异，并使这些差异作为增量区域流可用，以便在向订阅名称服务器的增量区域传输中使用。这看起来像以下内容：
xxxxxxxxxxoptions { // ... ixfr-from-differences yes; // ...};如上所述，DNS防火墙最简单、最常见的用途是通过简单地使域名消失来毒害已知的纯恶意域名。所有DNS RPZ规则都表示为资源记录集（RRset），表示“强制名称不存在条件”的方法是添加指向根域（.）的CNAME。在实践中，这看起来像：
xxxxxxxxxx$ORIGIN rpz.example.com.malicious1.org CNAME .*.malicious1.org CNAME .malicious2.org CNAME .*.malicious2.org CNAME .在这个例子中有两件事值得注意。首先，恶意名称在响应策略区域内是相对的。由于上述示例中“.org”后面没有尾随点，因此在扩展后，此响应策略区域内创建的实际RR集为：
xxxxxxxxxxmalicious1.org.rpz.example.com. CNAME .*.malicious1.org.rpz.example.com. CNAME .malicious2.org.rpz.example.com. CNAME .*.malicious2.org.rpz.example.com. CNAME .其次，对于每个被毒化的名字，还会列出一个通配符。这是因为恶意域名可能具有或可能具有恶意子域。
在上述示例中，相对域名 malicious1.org 和 malicious2.org 将分别仅与真实域名 malicious 1.org 和 malicious 2.org 匹配。相对域名 *.malicious1.org 和 *.malicios2.org 将分别与任何subdomain.of.malicious1.org 或 subdomain.of.malicious2.org 匹配。
此示例强制NXDOMAIN条件作为其策略操作，但其他策略操作也是可能的。
从9.10版本开始，BIND可以根据查询客户端的身份和查询的性质配置为具有不同的响应策略。要配置BIND响应策略，将信息放入一个区域文件中，该文件的唯一目的是将策略信息传递给BIND。包含响应策略信息的区域文件称为响应策略区域，或RPZ，BIND中使用这些区域中信息的机制称为DNS RPZ。
在BIND的单个实例中可以使用多达64个单独的RPZ文件，并且BIND不会因RPZ的大量使用而显著减慢速度。
（注意：默认情况下，BIND 9.11最多只支持32个RPZ文件，但在编译时可以增加到64个。所有其他支持的BIND版本默认支持64个。）
每个策略区域文件都可以根据需要为多个不同的域指定策略。64的限制是独立指定的策略集合的数量，而不是它们指定策略的区域数量。
来自所有策略区域的策略信息一起存储在一个特殊的数据结构中，允许非常快速地跨所有策略区域进行同时查找。查找策略规则与最大单个策略区域中规则数量的对数成正比。
订阅外部发布的DNS策略区域并拥有大量内部递归名称服务器的管理员应创建一个名为“分发主机”（DM）的内部名称服务器。从发布者的角度来看，DM是一个辅助（隐形辅助）名称服务器；即DM正在从外部服务器获取区域内容。从内部递归名称服务器的角度来看，DM也是一个主要的名称服务器：它们从DM获取区域内容。在这种配置中，DM充当外部发布者和内部订阅者之间的网关。
主服务器必须知道每个订阅递归服务器的单播侦听器地址，并且必须枚举所有这些地址作为实时区域更改通知的目的地（如RFC 1996中所述）。因此，如果一个企业范围的RPZ名为“rpz.example.com”，并且四个订阅递归名称服务器的单播侦听器地址为192.0.200.1、192.0201.1、192.0202.1和192.0203.1，则主服务器的配置如下：
xxxxxxxxxxzone "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; };};订阅策略区域的每个递归DNS服务器都必须配置为该区域的辅助服务器，并且还必须配置为将策略区域用于本地响应策略。要将递归名称服务器订阅到主服务器的单播侦听器地址为192.0.220.2的响应策略区域，服务器的配置应该如下：
xxxxxxxxxxoptions { // ... 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; };};请注意，查询仅限于“localhost”，因为DNS RPZ本身从不使用查询访问权限，但对于DNS操作员在调试中使用可能很有用。应禁止传输，以防止策略信息泄露。
如果一个组织的业务连续性取决于与另一家公司的完全连接，而该公司的ISP也为一些犯罪或虐待客户提供服务，那么一个或多个外部RPZ提供商（即安全馈送供应商）最终可能会添加一些RPZ规则，这可能会损害公司与其业务合作伙伴的连接。用户可以通过使用内部RPZ以及任何外部RPZ来保护自己免受这种风险，并在其内部RPZ中加入一些“传递”规则，以防止任何策略操作影响涉及业务合作伙伴的DNS响应。
递归DNS服务器可以连接到多个RPZ，并按顺序搜索这些RPZ。因此，为了保护网络免受有朝一日可能出现在外部RPZ区域的危险策略的影响，管理员应首先列出内部RPZ区域。
xxxxxxxxxxoptions { // ... response-policy { zone "rpz.example.com"; zone "rpz.security-vendor-1.com"; zone "rpz.security-vendor-2.com"; }; // ...};在内部RPZ中，需要制定规则来描述需要保护通信的业务合作伙伴的网络资产。虽然通常不可能知道他们使用什么域名，但管理员会知道他们有什么地址空间，也许还有他们使用的名称服务器名称。
xxxxxxxxxx$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.在这里，我们知道地址块10.0.0.0/8中的答案表示业务合作伙伴，以及涉及地址在128.45.0.0/16地址块中的任何名称服务器的答案，以及涉及名称为ns.partner1.com或ns.partners2.com的名称服务器的回答。
上面的示例演示了当按应答IP地址（.rpz IP所有者）、按名称服务器IP地址（.repz-nsp所有者）或按名称服务器域名（.rpz-nsdname所有者）进行匹配时，特殊的rpz标记（.rpz-IP、.rpz-nsip或.rpz-ns.dname）不会作为CNAME目标名称的一部分出现。
通过使用合作伙伴的已知网络资产触发这些规则，并使用“传递”策略操作，以后的RPZ处理（在上述示例中是指“rpz.security-vendor-1.com”和“rpz.security-vendor-2.com”策略区域）将不会对合作伙伴资产的DNS响应产生任何影响。
可能的情况是，攻击者唯一知道的是他们用于“钓鱼”网络服务器的IP地址块。如果他们使用的域名和名称服务器未知，但已知他们的每个“钓鱼”网络服务器都在一小块IP地址内，则可以使用RPZ规则对所有包含此地址范围内记录的答案触发响应，如下例所示：
xxxxxxxxxx$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 .在这里，如果真实答案包括一个A（address——地址）RR（resource record —— 资源记录），其值在109.94.212.0/22地址块内，则发送一个合成答案而不是真实答案。假设查询的是 www.malicious.net ，综合答案是：
xxxxxxxxxxwww.malicious.net. CNAME drop.garden.example.com.drop.garden.example.com. A 192.168.7.89
这假设 drop.garden.example.com 是在RPZ之外创建的真实DNS内容：
xxxxxxxxxx$ORIGIN example.com.drop.garden A 192.168.7.89在这个例子中，CNAME目标名称中没有“*”，因此原始查询名称将不会出现在围墙花园web服务器的日志文件中。这是一种不希望的信息丢失，此处仅作为示例。
上面的示例RPZ规则也会影响不需要的地址的地址到名称（也称为“reverse DNS”，反向DNS）查找。如果邮件或web服务器从示例的109.94.212.0/22地址块中的地址接收到连接，它将执行PTR记录查找，以找到与该IP地址关联的域名。
这种地址到名称的转换通常用于诊断或记录目的，但电子邮件服务器也会拒绝来自没有地址到名称转换的IP地址的任何电子邮件。来自这些IP地址的大多数邮件都是垃圾邮件，因此这里缺少PTR记录具有一定的预测价值。通过对与地址块关联的PTR名称空间中的所有查找使用“force name-does-not-exist”策略触发器，DNS管理员可以向其服务器发出提示，表明这些IP地址可能正在发送垃圾。
响应策略区域(Response Policy Zones)为每个规则定义了几个可能的触发器，已知这两个触发器会产生不一致的结果。这不是bug；相反，它与DNS委托模型中的不一致有关。
在DNS授权数据中，不在DNS区域顶点的NS RRset会创建一个子区域。该子区域的数据与当前（或“父”）区域是分开的，并且它可以具有与当前区域不同的权威名称服务器。通过这种方式，根区域指向COM、NET、ORG等，每个区域都有自己的名称服务器和管理其权威数据的方式。同样，ORG也有代表团参加ISC。ORG和数以百万计的其他“点ORG”区域，每个区域都有自己的一套权威名称服务器。按照协议的说法，位于区域顶点以下的这些NS RR集称为“委派点”。委派点处的NS RR集包含一个权威服务器列表，父区域将委派点或委派点以下所有名称的权限委派给这些服务器。
在每个区域的顶点也有一个NS RRset。理想情况下，这个所谓的“apex NS RRset”应该与父区域中的“delegation point NS RRset“相同，但这一理想并不总是能够实现。在真实的DNS中，区域管理员更新其中一个NS RR集几乎总是比更新另一个更容易，因此一个是正确的，另一个是过时的。这种不一致是如此普遍，以至于它必然是无害的：以这种方式不一致的域不太可靠，可能也较慢，但只要每个NS RR集和真相之间存在一些重叠，它们仍然可以正常工作。（在这种情况下，“真相”是指对该区域具有权威性的实际名称服务器集。）
在DNS递归名称服务器中，无法从本地缓存回答的传入查询将被发送到查询名称的最近已知委派点。例如，如果服务器正在查找XYZZY.ISC.ORG和它是ISC.ORG的名称服务器，然后直接将查询发送到这些服务器；然而，如果它以前从未听说过ISC.ORG，它必须首先将查询发送到ORG的名称服务器（甚至可能发送到作为ORG父级的根区域）。
当它询问其中一个父名称服务器时，该服务器将没有答案，因此它发送了一个仅由“委派点NS RRset”组成的“referral”(转介)。一旦服务器收到此转介，它就会通过再次发送相同的查询进行“迭代”，但这次是针对查询名称中更具体的部分命名服务器。最终，这种迭代会终止，通常是从查询名称的权威服务器获得答案或“名称错误”（NXDOMAIN），或者遇到某种类型的服务器故障。
当查询名称的权威服务器发送答案时，它可以选择包含该区域顶点NS RRset的副本。如果发生这种情况，递归名称服务器将缓存此NS RRset，替换它在迭代过程中收到的委派点NS RRset。用DNS的说法，委托点NS RRset是“glue”(胶水)，意思是非权威数据，或者更多的是暗示而不是真实的事实。另一方面，顶点NS RRset是权威数据，它来自区域本身，被认为比“胶水”更可信。因此，顶点NS RR set的正确性比委托点NS RRset的正确性感到更重要，因为前者将迅速取代后者，并且将在更长的总时间内被更频繁地使用。
重要的是，权威名称服务器不需要在任何答案中包含其顶点NS RRset，递归名称服务器通常不会直接查询此RRset。因此，顶点NS RRset可能完全错误，而不会产生任何操作上的不良影响，因为不需要暴露错误的数据。当然，如果此NS RRset有查询，大多数递归名称服务器会将查询转发到该区域的权威服务器，因为当被问及特定问题时返回“粘合”数据是不好的。在这些极端情况下，根据递归名称服务器处理的其他查询，错误的顶点NS RRset数据可能会导致区域不可预测地变得无法访问。
还有另一种“胶水”，用于名称低于委托点的名称服务器。如果ORG委托ISC.ORG改为NS-EXT.ISC.ORG服务器需要知道NS-EXT.ISC.ORG的地址，并将此地址作为代表团回复的一部分返回。但是，此名称服务器的名称到地址绑定仅在ISC.ORG区内部具有权威性；因此，与代表团一起给出的A或AAAA RRset是非权威的“胶水”，如果看到权威的RRset，就会被替换。与顶点NS RRset一样，递归名称服务器不会自动查询真实的A或AAAA RRset，但如果传入查询要求此RRset，则会查询该RRset。
RPZ有两种触发器类型，旨在允许策略区域作者基于所有由相同DNS服务器服务的域来定位整个域组：NSDNAME和NSIP。NSDNAME和NSIP规则分别与答案所在区域及其所有父区域的名称服务器的名称和IP地址进行匹配。在默认配置中，BIND会主动获取任何丢失的NS RRset和地址记录。如果在尝试解析所有这些委托服务器名称的过程中，BIND收到任何查询的SERVFAIL响应，则中止策略规则评估并返回查询的SERFFAIL。从技术上讲，这既不是规则的匹配，也不是规则的不匹配。
完全限定域名（FQDN）中的每个“.”都代表一个潜在的委派点。当BIND搜索父区域NS RRset（以及在NSIP的情况下，其附带的地址记录）时，它必须检查每个可能的委托点。这可能会成为一些专用伪域的问题，例如一些域名和网络信誉系统，它们的名称中有许多“.”字符。如果该系统还具有不兼容的DNS服务器，这些服务器会默默地丢弃对NS和SOA记录的查询，则情况会更加复杂。这迫使BIND等待这些查询超时，然后才能完成对策略规则的评估，即使这比合理的客户端通常等待答案的时间要长（观察到超过60秒的延迟）。
虽然这两种情况都涉及技术上“损坏”的配置和/或服务器，但由于冗余和迭代优化，它们仍可能在RPZ NSIP和NSDNAME规则之外“工作”。
有两个RPZ选项，nsip-wait-recurse 和 nsdname-wait-recurse ，分别允许BIND在评估nsip和nsdname规则时仅使用缓存中已存在的记录，从而改变BIND的行为。
因此，NSDNAME和NSIP规则是不可靠的。这些规则可以与顶点NS RRset或“胶水”NS RRset相匹配，每个规则都有其关联的地址（也可能是“胶水”，也可能不是）。为了确保在RPZ中正确使用NS和NSIP触发器，发现委托名称服务器名称和地址以及顶点名称服务器名称及权威地址记录符合管理员的利益。即便如此，仅仅通过制定NSIP和NSDNAME规则，可能会对完全无关的域造成附带损害，否则这些域将“正常工作”。
Mozilla于2019年9月宣布，他们将为Firefox浏览器的所有美国用户启用DNS over HTTPS（DoH），将所有DNS查询发送给预定义的DoH提供商（特别是Cloudflare的1.1.1.1服务）。对于一些不希望用户的DNS查询意外重新路由的网络管理员来说，这是一个问题。但是，Mozilla提供了一种默认设置禁用DoH的机制：如果Mozilla拥有的域use-application-dns.net返回NXDOMAIN响应代码，Firefox将不会使用DoH。
要使用RPZ完成此操作：
创建一个名为 mozilla.rpz.db 的polizy区域文件，配置为在任何use-application-dns.net 的查询中都会返回NXDOMAIN：
xxxxxxxxxx$TTL 604800$ORIGIN mozilla.rpz.@ IN SOA localhost. root.localhost. 1 604800 86400 2419200 604800@ IN NS localhost.use-application-dns.net CNAME .将该区域添加到BIND配置中（通常是 named.conf）：
xxxxxxxxxxzone mozilla.rpz {type primary;file "/<PATH_TO>/mozilla.rpz.db";allow-query { localhost; };};
通过将响应策略指令添加到 optinos {} 部分，为所有传入查询启用 response-policy 区域：
xxxxxxxxxxoptions { response-policy { zone mozilla.rpz; } break-dnssec yes;};重新加载配置并测试刚刚添加的响应策略区域是否有效：
xxxxxxxxxx# 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>响应应返回NXDOMAIN而不是IP地址列表，BIND 9日志应包含以下行：
xxxxxxxxxx09-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.rpz09-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请注意，这是最简单的配置；具体的配置可能不同，特别是对于已经在使用其他响应策略区域或其服务器配置了多个视图的管理员。