一旦我面临着赋予客户之一权限编辑分配给它的子网/ 28的PTR记录的任务。 我没有从外部编辑BIND设置的自动化工具。 因此，我决定采用另一种方式-将一部分PTR / 24子网区域委派给客户端。
似乎-哪个更容易？ 我们只是以正确的方式规定了子网，然后将其定向到所需的NS，就像使用子网域一样。 但是没有 它不是那么简单（尽管实际上通常是原始的，但是直觉却无济于事），这就是我编写本文的原因。
谁想自己弄清楚，可以阅读
RFC谁想要现成的解决方案，欢迎光临。
为了不耽误那些喜欢复制粘贴方法的人，我将首先介绍实践部分，然后再讨论理论部分。
1.练习。 委派区/ 28假设我们有一个
7.8.9.0/24的子网。 我们需要将子网
7.8.9.240/28委派给dns客户端
7.8.7.8 （
ns1.client.domain ）。
在提供商DNS上，您需要找到一个描述此子网反向区域的文件。 使其为
9.8.7.in-addr.arpa 。
如果有评论，则评论从240到255。 在文件末尾，编写以下内容：
255-240 IN NS 7.8.7.8 $GENERATE 240-255 $ CNAME $.255-240
别忘了增加串行区域并做
rndc reload
至此，提供者部分结束了。 我们传递给客户端dns。
首先，
使用以下内容创建
/etc/bind/master/255-240.9.8.7.in-addr.arpa文件：
$ORIGIN 255-240.9.8.7.in-addr.arpa. $TTL 1W @ 1D IN SOA ns1.client.domain. root.client.domain. ( 2008152607 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum @ IN NS ns1.client.domain. @ IN NS ns2.client.domain. 241 IN PTR test.client.domain. 242 IN PTR test2.client.domain. 245 IN PTR test5.client.domain.
然后在
named.conf中添加新文件的描述：
zone "255-240.9.8.7.in-addr.arpa." IN { type master; file "master/255-240.9.8.7.in-addr.arpa"; };
B重新启动绑定过程。
/etc/init.d/named restart
仅此而已。 现在您可以检查了。
#> host 7.8.9.245 245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa. 245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.
请注意，不仅提供了PTR记录，还提供了CNAME。 应该是这样。 如果您想知道为什么，那么欢迎进入下一章。
2.理论。 如何运作？配置和调试黑匣子很困难。 如果您了解内部正在发生的事情，则容易得多。
当我们在domain
domain中委派一个子
域时 ，我们将编写如下内容：
client.domain. NS ns1.client.domain. ns1.client.domain. A 7.8.7.8
我们告诉所有人，我们对本网站不负责，我们说谁负责。 并且所有对
client.domain的请求
都重定向到7.8.7.8。 检查时，我们看到以下图片（忽略客户端的内容。没关系）：
# host test.client.domain test.client.domain has address 7.8.9.241
即 我们被告知存在这样的A记录及其IP 7.8.9.241。 没有不必要的信息。
但是，如何通过子网完成同一件事？因为 由于我们的DNS服务器已在RIPE中注册，因此当从我们的网络请求PTR IP地址时，第一个请求仍将发送给我们。 逻辑与域相同。 但是，如何在区域文件中输入子网？
我们尝试这样输入：
255-240 IN NS 7.8.7.8
而且……没有发生奇迹。 我们没有收到任何请求重定向。 问题是，bind根本不知道反向区域文件中的这些条目是ip地址，甚至更多，因此它们不了解范围条目。 对他来说，这只是一个符号子域。 即 对于绑定，“
255-240 ”和“
oursuperclient ”之间没有区别。 并且将请求发送到原处的请求，请求中的地址应如下所示：
241.255-240.9.8.7.in-addr.arpa 。 如果我们使用字符子域，则也可以这样：
241.oursuperclient.9.8.7.in-addr.arpa 。 这与通常的方法不同：
241.9.8.7.in-addr.arpa 。
双手这样的要求将是有问题的。 如果能解决问题，目前尚不清楚如何在现实生活中应用它。 毕竟，在
7.8.9.241的请求下，提供者DNS（而不是客户端的DNS）仍然可以回答我们。
CNAME在这里发挥作用。
在提供者端，您需要为子网的所有IP地址创建别名，该别名的格式应将请求转发到客户端DNS。
255-240 IN NS ns1.client.domain. 241 IN CNAME 241.255-240 242 IN CNAME 242.255-240 ..
这是为了努力=）。
对于懒惰的人，以下设计更适合：
255-240 IN NS ns1.client.domain. $GENERATE 240-255 $ CNAME $.255-240
现在，从提供商的dns服务器上的
241.9.8.7.in-addr.arpa在
7.8.9.241处获取信息的请求将转换为
241.255-240.9.8.7.in-addr.arpa ，并将转到dns客户端。
客户将需要处理此类请求。 因此，我们在
255-240.9.8.7.in-addr.arpa中创建一个区域。 在其中，我们基本上可以发布整个/ 24子网中任何IP的反向记录，但只会询问提供商将重定向到我们的反向记录，因此您将无法使用=）。
为了说明，我将在客户端给出反向区域文件内容的示例：
$ORIGIN 255-240.9.8.7.in-addr.arpa. $TTL 1W @ 1D IN SOA ns1.client.domain. root.client.domain. ( 2008152607 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum @ IN NS ns1.client.domain. @ IN NS ns2.client.domain. 241 IN PTR test.client.domain. 242 IN PTR test2.client.domain. 245 IN PTR test5.client.domain.
这是由于我们在提供者方面使用了CNAME，并且响应ip地址上的数据请求，我们得到了两条记录，而不是一条。
#> host 7.8.9.245 245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa. 245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.
并且不要忘记正确配置ACL。 因为自己为自己设置PTR区，而不从外面回答任何人=）是没有意义的。