指定/部署

概述

Moniker 架构使用代理来执行 DNS 服务器的 DNS 更改。API 通过 RPC 与代理通信。本文将探讨此设计对多种场景下 Moniker 部署的影响。

DNS 概述

在不深入探讨 DNS 工作原理的细节的情况下，对于本次讨论，我们只关注部署方面。典型的、大规模的 DNS 基础设施由以下部分组成：

• 权威服务器：能够为查询直接由该服务器管理的区域提供结果
• 缓存服务器：能够代表权威服务器提供结果，并缓存结果

区域和记录在权威服务器上配置，而缓存服务器只需要配置区域。

部署选项

仅文件

例如，Bind9。

在这种情况下，Moniker 代理需要在权威服务器和缓存服务器上运行。需要本地更新文件，并可以使用 rndc 重新加载区域。Moniker 需要了解基础设施中的所有服务器，并可能区分权威服务器和缓存服务器。

集中式权威服务器和分布式缓存服务器

例如：使用 DB/LDAP 后端的 PowerDNS 和 PowerDNS 缓存服务器。

PowerDNS 允许通过多种后端（例如数据库或 LDAP）配置权威服务器。此选项不需要在每个权威服务器上运行代理，因为可以通过单个代理远程连接到 DB 或 LDAP 来执行配置

目前 Moniker 具有每个服务器的资源，在这种情况下，该资源将不代表权威服务器，而是与 DB 或 LDAP 通信的代理，多个权威服务器可以共享相同的后端

但是，缓存服务器仍然需要部署代理，因为它们不从后端读取。这意味着要配置要缓存的新区域，必须更改其配置。Moniker 将为每个缓存服务器提供一个资源，并且需要区分权威服务器和缓存服务器，因为它们的配置机制不同。

完全集中式

例如：Nominum ANS 和 Vantio

此部署选项对权威服务器和缓存服务器的配置都使用集中式配置（通过 API）。代理不需要了解基础设施中的每个服务器，而只需要执行配置请求的代理。

结论

与仅集中式架构相比，使用代理执行 DNS 基础设施配置具有优势。为了完全支持上述用例，有两种选择：

• 代理的分布模型特定于后端的选择，在这种情况下，API 不应假定部署模型，并让后端定义部署架构。这意味着 Moniker API 中的服务器资源应完全由后端管理
• Moniker 了解不同的部署选项并完全管理这些选项。它需要扩展服务器资源以允许配置多种用例。