![CIDR 世界中的反向 DNS](https://linux22.com/image/484902/CIDR%20%E4%B8%96%E7%95%8C%E4%B8%AD%E7%9A%84%E5%8F%8D%E5%90%91%20DNS.png)
反向 DNS 似乎与类边界紧密相关,既然 CIDR 是委派子网权限的标准,那么现在有哪些方法?如果存在多种方法,哪一种最好?您是否需要根据 DNS 服务器(Bind、djbdns、Microsoft DNS 等)以不同方式处理委派?假设我控制的是 B 类网络 168.192.in-addr.arpa,请提供以下示例:
- 如何为/22 委托权限?
- 如何为/25 委托权限?
答案1
委派 /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 文件中,我会像任何正常的 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.
因此,它在概念上与其他想法类似,但不是创建新区域并将其委托给客户,而是将记录 CNAME 到客户已经存在的主区域中的名称。
客户在其 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 完成了客户端的工作。我看不出它不能与任何服务器兼容的原因。
答案2
答案3
BIND 具有专有的 $GENERATE 宏,用于创建 PTR 记录序列,但它也假设了一个有类别的世界,对您来说用处不大。我不知道有任何其他服务器对 CIDR 反向区域有特殊支持,尽管我怀疑有这方面的需求!
PowerDNS 有一个不错的后端接口,如果问题足够大,值得付出努力,您可以编写自己的接口。您还可以使用“PipeBackend”进行原型设计。您甚至可以通过 MySQL/PostgreSQL 接口执行一些神奇的 SQL 操作 - 特别是因为 Postgres 有一个“cidr”数据类型。
答案4
http://aa.net.uk/kb-domains-reversedns.html(大约一半)解释了我的 ISP 如何执行其反向 DNS。我怀疑无论你怎么做,它都会很糟糕。