CIDR世界中的反向DNS

反向DNS似乎与类边界紧密相关，既然CIDR是委派子网权限的标准，那么现在存在哪些方法？如果存在多种方法，哪一种最好？您是否需要根据DNS服务器（绑定，djbdns，Microsoft DNS等）不同地处理委派？可以说我控制的网络是B级168.192.in-addr.arpa，请提供以下示例：

• 如何为/ 22委派权限？
• 如何为/ 25委派权限？

委派/ 22很容易，这是4/24的委派。/ 14是4/16的委托，依此类推。

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              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文件中，我将使PTR像任何普通的in-addr.arpa区域一样：

17                 IN PTR office.customer.com.
18                 IN PTR www.customer.com.
(etc)

这样做是一种干净的方法，它使精明的客户满意，因为他们有in-addr.arpa区域可放入PTR等。对于想要控制反向DNS但不希望反向DNS的客户而言，这是一种较短的方法想要设置整个区域只是将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.

因此，它在概念上与另一个想法相似，但是您不是在创建新区域并将其委派给客户，而是将记录命名为客户已经存在的主区域中的名称。

客户在他们的customer.com区域文件中将具有以下内容：

office             IN A   172.16.23.17
17                 IN PTR office.customer.com.
www                IN A   172.16.23.18
18                 IN PTR www.customer.com.
(etc)

这仅取决于客户的类型。就像我说的，这仅取决于客户类型。精明的客户会喜欢设置自己的in-addr.arpa区域，并且会认为在域名区域中拥有PTR非常奇怪。一个不懂行的客户会希望它“正常工作”而不必做大量的额外配置。

可能还有其他方法，仅详述我所熟悉的两种方法。

我只是在思考关于/ 22和/ 14多么容易的声明，并思考为什么这是正确的，但很难理解25到32之间的任何值。我还没有对此进行测试，但是如果您可以将整个/ 32委托给客户，我会徘徊：

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完成了此方面的工作。我看不出它不适用于任何服务器的原因。

是的，RFC 2317是一本很好的书，是必经之路。

另外，我的文章（法文）。

BIND具有专有的$ GENERATE宏，可用于创建PTR记录序列，但它也具有一个世界分类，对您不是很有用。我不知道有任何其他对CIDR反向区域具有特殊支持的服务器，尽管我怀疑对此有需求！

PowerDNS有一个不错的后端接口，如果问题足够大，值得您全力以赴，您可以编写自己的后端接口。您也可以使用“ PipeBackend”创建原型。您甚至可以通过MySQL / PostgreSQL接口执行一些魔术SQL任务-尤其是因为Postgres具有“ cidr”数据类型。

http://aa.net.uk/kb-domains-reversedns.html（大约下降了一半）介绍了我的ISP如何进行其反向DNS。我怀疑您所做的任何方式都会像地狱一样丑陋。