在CIDR世界中反向DNS

反向DNS似乎与类边界紧密联系在一起,现在有哪些方法存在CIDR是委托子网权限的标准? 如果存在多种方法哪一个最好? 您是否需要根据DNS服务器(绑定,djbdns,Microsoft DNS,其他)以不同方式处理委派? 比方说,我有一个B类networking的控制168.192.in-addr.arpa请提供的例子:

  • 如何委托一个/ 22的权力?
  • 如何委托一个/ 25的权力?

    委托一个/ 22很容易,这是4 / 24s的代表团。 A / 14是4/16的代表团等

    RFC2317涵盖了大于/ 24的networking掩码的特殊情况。 基本上,除了八位字节的边界之外,没有超级干净的方法可以对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创buildCNAME,将其委托给新委派区域下的相应编号。

    作为这些被委派的客户,我会在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区域来放置PTRs等等。对于想要控制反向DNS的客户来说,要设置一个完整的区域就是将CNAME个人logging转换为主区域中的相似名称。

    在这种情况下,作为代理人,我们的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. 

    所以它在概念上与其他想法相似,而不是创build一个新区域并将其委托给客户,而是将loggingCNAME化到客户已有的主区域中的名称。

    客户在他们的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) 

    这只取决于客户的types。 就像我说的,这只取决于客户types。 一个精明的客户会更喜欢build立他们自己的in-addr.arpa区域,并认为在一个域名区域中存在PTR是很奇怪的。 一个非精明的客户会希望它“只是工作”,而不必做大量的额外configuration。

    有可能的其他方法,只是详细说明我熟悉的两个。


    我只是在考虑我/ 22和/ 14的说法是否容易,并且考虑了为什么这是真的,但25到32之间的任何事情都很难。 我还没有testing过这个,但是如果你能把整个/ 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的全部function。 我的例子显然是使用BIND,但是我们使用Windows DNS和BIND完成了客户端。 我没有看到任何服务器无法使用的原因。

    是的, RFC 2317是一个非常不错的阅读方法。

    另外, 我的文章 (法文)。

    BIND拥有用于创buildPTRlogging序列的专有的$ GENERATEmacros,但它也假定有一个有类的世界,对你来说不会很有用。 我不知道有任何其他服务器对CIDR反向区域有特别的支持,虽然我怀疑是否有需求!

    PowerDNS有一个很好的后端界面,如果问题足够大,可以让你编写自己的代码。 您也可以使用“PipeBackend”的原型。 你甚至可以通过MySQL / PostgreSQL接口做一些神奇的SQL东西 – 尤其是因为Postgres有一个“cidr”数据types。

    http://aa.net.uk/kb-domains-reversedns.html (下半程左右)解释了我的ISP如何做他们的反向DNS。 我怀疑你做任何事情都会像地狱一样丑陋。