domain-name-system – CIDR世界中的反向DNS

前端之家收集整理的这篇文章主要介绍了domain-name-system – CIDR世界中的反向DNS前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
反向DNS似乎与类边界紧密相关,现在有哪些方法CIDR是委派子网权限的标准?如果存在多种方法哪种方法最好?您是否需要以不同的方式处理委派,具体取决于DNS服务器(Bind,djbdns,Microsoft DNS,其他)?假设我控制了一个B类168.192.in-addr.arpa的网络,请提供以下示例:

>如何委派/ 22的权限?
>如何委派/ 25的权限?

解决方法

委托a / 22很容易,它是4/24的代表团. A / 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文件中,我会像任何正常的in-addr.arpa区域一样制作PTR:

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

这是一种干净的方式,它让精明的客户感到高兴,因为他们有一个in-addr.arpa区域可以放入PTR,等等.对于想要控制反向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完成了客户端.我没有看到它不适用于任何服务器的原因.

猜你在找的HTML相关文章