我运行一个反向/ 16区域的权威名称服务器，其中每个IP映射到一个自定义子域。 这是通过带有256 $GENERATE指令的区域文件实现的，例如（子网11.22.0.0/16）：
$GENERATE 0-255 $.1 PTR $.1.22.11.rev.example.com. $GENERATE 0-255 $.2 PTR $.2.22.11.rev.example.com. (...)
这工作正常，唯一的问题是，每当我们添加一个“有意义的”反向logging（ 4.3.22.11.in-addr.arpa. IN PTR www.example.com. ），将导致有2个PTRlogging对于相同的IP地址：
4.3.22.11.in-addr.arpa. IN PTR www.example.com. 4.3.22.11.in-addr.arpa. IN PTR 4.3.22.11.rev.example.com.
在大多数情况下，这是好的，但在某些情况下，我们需要有一个单一的PTRlogging。
解决方法是将$GENERATE块“展开”为单独的PTRlogging，并replace违规的logging。 有没有办法来覆盖生成的logging，而不必扩大整个范围？
该名称服务器在RHEL6上运行BIND 9.8.2。
$GENERATE指令只有两种范围 ：开始 – 停止或开始 – 停止/步骤。 正因为如此，你不能排除范围内的一个IP，但你必须相应地分割范围，例如
$ORIGIN 22.11.in-addr.arpa. $GENERATE 0-3 $.3 PTR $.3.22.11.rev.example.com. 4.3 PTR www.example.com. $GENERATE 5-255 $.3 PTR $.3.22.11.rev.example.com.
不幸的是没有办法做到这一点。 你坚持“展开”。
在内存中，$ GENERATE指令导致生成单独的PTRlogging。 这可以通过在区域传输后查看辅助服务器接收的区域文件来观察，该区域文件不包含$ GENERATE指令。 没有语法允许您select性地覆盖单个PTRlogging。
在火箭科学家DNS的第8章中提到了另外一种方法，它是添加一个使用named-checkzoneparsing出$ GENERATE指令的步骤，并用单独的PTRlogging代替它：
加载区域文件时执行$ GENERATE语句，在区域文件本身不变的情况下，将导致BIND9正在使用的区域的扩展内存版本。 如果你想看到扩展（你不相信结果或者你想编辑它），名为checkzone的绑定工具将允许创build一个扩展的区域文件（包括$ GENERATE指令），它可以被使用作为模板（或骨架）并随后进行编辑。 作为使用named-checkzone的一个副作用，任何不合格的标签（名称）也将被扩展为完整的FQDN，任何$ TTL指令将被用于填充单独的RR TTL。 这可能会，也可能不会是一个有用的副作用。 假设包含$ GENERATE指令的区域文件是192.168.199.rev（按照本指南的区域文件命名约定），并且区域名称是199.168.192.IN-ADDR.ARPA，那么以下命令将输出扩展区域文件到192.168.199.rev.exp。
named-checkzone -D -o 192.168.199.rev.exp 199.168.192.IN-ADDR.ARPA 192.168.199.rev
不利的一面是，自然，你的主文件区域文件变得更大。 在这一点上，你只使用$ GENERATE为你创build初始的反向区域，这样就不需要手工input单独的PTRlogging，而且shell脚本可以很容易地在那里达到相同的最终结果。
这可能不是你所希望的解决办法，但不幸的是这是事态的状态。 🙁