为什么这些反向查询DNS容器变灰？
我们在2008年DNS中有一个反向查找区域，名称为：
220.10.in-addr.arpa （我会称之为“母区”），它是从3个不同的子区域/子区域托pipelogging：
10.220.0.x, 10.220.1.x和10.220.2.x.
在尝试将一个区域的logging与其他区域分开时，我最初创build了两个区域，即0.220.10.in-addr.arpa和1.220.10.in-addr.arpa ，这些区域正在复制到域中的所有DNS服务器。 起初，这些区域与220.10.in-addr.arpa出现在相同的水平，但过了一段时间后，除了我创build的个别区域之外，在每个子区域出现了两个灰色的容器。
- 正确的方式来设置我的DNS（在GoDaddy上）与RackServer一起使用？
- 我如何在基于Windows Server的networking中设置DNS？
- 防止MXlogging回退
- DNS不能parsing根域名，只能为子域名parsing
- 如何访问托pipe在专用服务器上的过期域名网站，而无需进行任何configuration
为什么这些容器变灰，为什么一开始就不出现？ 变灰意味着他们被委派？
谢谢。
当您为父networking10.220创buildrDNS区域时，DNS服务将自动在父区域（networking）的每个子网的父区域下创build一个子区域，以便在来自这些子网的客户机注册其PTRlogging时发现它。 由于DNS服务已经发现您已经为这些子网创build了区域，因此您已经完成了父区域下的委派区域，因此它会在指向您手动创build的区域的父区域下创build委派区域。
我更喜欢这样做的方法是为父networking创build一个rDNS区域，并让来自这些子网的客户端注册其PTRlogging时，DNS服务创build子区域。 这是你所做的相反，所以让我澄清一下：
如果要为每个子网手动创build区域，则不要为父networking创build区域（10.220）。
如果您希望DNS服务器为属于10.220networking/ DNS区域的子网创build子区域，请删除手动创build的10.220.0和10.220.1区域。
是的，那些应该是代表团 – 如果你点击它们，唯一存在的NSlogging是正确的？
他们很可能是由DNS服务器自动产生的，因为它知道它有一些分层的东西。