bind9 转发记录,而不仅仅是区域

bind9 转发记录,而不仅仅是区域

我面临的情况是,我有几个使用 UltraDNS 托管的域名,还有一个 bind9 服务器,用于本地使用内部子域名和 dhcp 主机名。

例如,domain.com 由 UltraDNS 托管,同一个域名在本地被 bind9 用于 dhcp 和内部地址,例如 dyndns09.domain.com 和 internal.domain.com。

我希望发生的是,如果 bind9 中不存在子域,它将使用指定的转发器之一来查找该地址。

据我所知,解决此问题的一个常见方法是使用绑定视图根据子网定义使用哪些区域,但由于 UltraDNS 是 DNS 即服务,因此这不是一个选项。另一个常见的解决方案是使用 dnsmasq - 不幸的是,这也是一个问题。使用 dnsmasq 进行 DNS 而不使用 dnsmasq 作为 DHCP 服务器似乎不允许 DHCP 客户端使用真正的动态 DNS。

非常感谢对此的任何见解。

答案1

将 DHCP 用户与服务器放在同一个命名空间中是有风险的。为 DHCP 使用子域。然后,您可以轻松地将需要发送的内容转发到 DNS。

如果您对服务器地址进行 NAT,请确保启用发夹 NAT 或在本地服务器中复制具有适当地址的条目。在这种情况下,您将不会转发请求。

答案2

在两个“空间”中使用同一个域(例如具有相同名称的内部域和外部域)是非常令人困惑和危险的行为。但如果您必须这样做,则必须确保它们是分开的,但仍保持同步。如果同一个权威名称服务器回复来自内部和外部客户端的查询,您通常会使用视图,但在您的情况下,听起来它们是分开的。

在您的场景中,我会创建一个手动例程,即每个更新 domain.com 外部区域的人也必须更新本地 bind9 服务器上的内部版本,但我更愿意构建一个脚本解决方案,以便您只在外部服务器上更新外部 domain.com 区域,在您的情况下为 UltraDNS,然后我会保留一个包含内部计算机附加内容的本地文件,并通过脚本同步并将这两个区域合并到我加载/重新加载到本地绑定中的最终内部区域中。

脚本方法的复杂之处在于,如果区域中有相同的主机名,该主机名在外部指向一个 IP,在内部指向不同的 IP,您就必须考虑这一点并编写一些逻辑/异常来处理它。

根据更新区域的数量以及发生错误的可能性,我会选择外部/内部的手动更新或脚本版本。

相关内容