反向 DNS 似乎与类边界密切相关，既然 CIDR 是委派子网权限的标准，现在存在哪些方法？如果存在多种方法，哪一种最好？您是否需要根据 DNS 服务器（Bind、djbdns、Microsoft DNS 等）以不同方式处理委派？假设我控制了一个 B 类 168.192.in-addr.arpa 的网络，请提供以下示例：
16-29 IN NS ns1.customer.com
16-29 IN NS ns2.customer.com
16 IN CNAME 16.16-29.23.16.172.in-addr.arpa.
17 IN CNAME 17.16-29.23.16.172.in-addr.arpa.
18 IN CNAME 18.16-29.23.16.172.in-addr.arpa.
19 IN CNAME 19.16-29.23.16.172.in-addr.arpa.
20 IN CNAME 20.16-29.23.16.172.in-addr.arpa.
21 IN CNAME 21.16-29.23.16.172.in-addr.arpa.
22 IN CNAME 22.16-29.23.16.172.in-addr.arpa.
23 IN CNAME 23.16-29.23.16.172.in-addr.arpa.
因此，您可以看到我正在定义一个新区域 (16-29.23.16.172.in-addr.arpa.) 并将其委托给我客户的名称服务器。然后，我从要委派到新委派区域下的相应号码的 IP 创建 CNAME。
作为这些被委派给的客户，我会在 named.conf 中执行以下操作：
zone "16-29.23.16.172.in-addr.arpa" {
type master;
file "masters/16-29.23.16.172.rev";
};
然后在 .rev 文件中，我将像任何普通的 in-addr.arpa 区域一样制作 PTR：
17 IN PTR office.customer.com.
18 IN PTR www.customer.com.
(etc)
这是一种干净的方法，它让精明的客户感到高兴，因为他们有一个 in-addr.arpa 区域来放置 PTR，等等。对于想要控制反向 DNS 但不想要控制反向 DNS 的客户来说，这是一种更短的方法。 t 想要建立一个完整的区域只是将 CNAME 单独记录到其主区域中的相似名称。
在这种情况下，我们作为委托人，在我们的 23.16.172.rev 文件中会有这样的内容：
16 IN CNAME 16.customer.com.
17 IN CNAME 17.customer.com.
18 IN CNAME 18.customer.com.
19 IN CNAME 19.customer.com.
20 IN CNAME 20.customer.com.
21 IN CNAME 21.customer.com.
22 IN CNAME 22.customer.com.
23 IN CNAME 23.customer.com.
16 IN NS ns1.customer.com.
17 IN NS ns1.customer.com.
(etc)
然后，在客户端，您捕获整个 /32：
zone "16.23.16.172.in-addr.arpa" { type master; file "masters/16.23.16.172.rev"; };
zone "17.23.16.172.in-addr.arpa" { type master; file "masters/17.23.16.172.rev"; };
(etc)
然后在单个文件中，您将拥有如下内容：
@ IN PTR office.customer.com.
明显的缺点是每个 /32 一个文件有点恶心。但我敢打赌它会奏效。
我提到的所有东西都是纯 DNS，如果任何 DNS 服务器不允许你这样做，那是因为它限制了 DNS 的全部功能。我的示例显然使用了 BIND，但我们已经使用 Windows DNS 和 BIND 完成了客户端。我看不出它不适用于任何服务器的原因。
委派 /22 很容易，它是 4 /24 的委派。A /14 是 4 /16s 的委托，等等。
RFC2317涵盖了网络掩码长于 /24 的特殊情况。基本上，除了八位字节边界之外，没有任何超级干净的方法可以对 in-addr.arpa 区域进行委派，但您可以解决这个问题。假设我要委托 172.16.23.16/29，即 IP 地址 172.16.23.16 -> 172.16.23.23。
作为 23.16.172.in-addr.arpa 区域的所有者，我可能会将其放在我的 23.16.172.rev 区域文件中，以将此范围委托给我的客户：
因此，您可以看到我正在定义一个新区域 (16-29.23.16.172.in-addr.arpa.) 并将其委托给我客户的名称服务器。然后，我从要委派到新委派区域下的相应号码的 IP 创建 CNAME。
作为这些被委派给的客户，我会在 named.conf 中执行以下操作：
然后在 .rev 文件中，我将像任何普通的 in-addr.arpa 区域一样制作 PTR：
这是一种干净的方法，它让精明的客户感到高兴，因为他们有一个 in-addr.arpa 区域来放置 PTR，等等。对于想要控制反向 DNS 但不想要控制反向 DNS 的客户来说，这是一种更短的方法。 t 想要建立一个完整的区域只是将 CNAME 单独记录到其主区域中的相似名称。
在这种情况下，我们作为委托人，在我们的 23.16.172.rev 文件中会有这样的内容：
所以它在概念上与另一个想法相似，但不是创建一个新区域并将其委托给客户，而是将记录 CNAME 到客户已经存在的主区域中的名称。
客户的 customer.com 区域文件中会有类似的内容：
这仅取决于客户的类型。就像我说的，这取决于客户类型。精明的客户会更喜欢设置自己的 in-addr.arpa 区域，并且会认为在域名区域中拥有 PTR 非常奇怪。不精通的客户会希望它“正常工作”而无需进行大量额外配置。
可能还有其他方法，只详细介绍我熟悉的两种。
我只是在想我关于 /22 和 /14 如何简单的陈述，并思考为什么这是真的，但 25 到 32 之间的任何东西都很难。我没有对此进行测试，但是如果您可以像这样将整个 /32 委托给客户，我会徘徊：
然后，在客户端，您捕获整个 /32：
然后在单个文件中，您将拥有如下内容：
明显的缺点是每个 /32 一个文件有点恶心。但我敢打赌它会奏效。
我提到的所有东西都是纯 DNS，如果任何 DNS 服务器不允许你这样做，那是因为它限制了 DNS 的全部功能。我的示例显然使用了 BIND，但我们已经使用 Windows DNS 和 BIND 完成了客户端。我看不出它不适用于任何服务器的原因。
是的，RFC 2317是一本很好的读物，是要走的路。
另外，我的文章（法语）。
http://aa.net.uk/kb-domains-reversedns.html（大约一半）解释了我的 ISP 如何进行反向 DNS。我怀疑你这样做的任何方式都会变得丑陋。
BIND 具有用于创建 PTR 记录序列的专有 $GENERATE 宏，但它也假定有一个分类世界，对您来说不是很有用。我不知道有任何其他服务器对 CIDR 反向区域有特殊支持，尽管我怀疑有需求！
PowerDNS 有一个很好的后端界面，如果问题大到值得付出努力，您可以自己编写。您还可以使用“PipeBackend”进行原型设计。你甚至可以通过 MySQL/PostgreSQL 接口做一些神奇的 SQL 东西——特别是因为 Postgres 有一个“cidr”数据类型。