本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode

Catalog Zones

DNS Catalog Zones 是一种将区域目录表示为常规 DNS 区域，并使用 DNS 区域传输进行传输的方法。当区域被添加到或从目录区域中移除时，更改会以正常方式传播到辅助名称服务器。然后，辅助名称服务器会根据区域的更改添加/移除/修改它们所服务的区域。

(https://zones.cat/)

问题描述

目前 Designate 并没有为辅助名称服务器提供一个区域列表，以便它们可以从中获取并进行配置。相反，Designate 通过调用像 BIND 的 rndc 这样的管理工具，逐个手动创建、修改和删除每个区域。这种机制在向辅助服务器添加和维护大量域名时存在扩展性问题，并且在向服务器池中添加新服务器时收敛速度慢。

提议的变更

应该向 Designate 添加支持提供 catalog zones 的功能。

本质上，catalog zones 通过从特殊区域（catalog）进行 AXFR 传输，为辅助服务器提供易于配置的区域列表。

以下链接解释了 catalog zone 功能、用例和数据模型

• https://zones.cat/

• https://kb.isc.org/docs/aa-01401

• https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/

BIND9、Knot 和其他主要的 DNS 服务器（如 PowerDNS 或 NSD）已经支持消耗 catalog zones，它们都是 Designate 支持的后端。

• BIND (>=9.11) https://bind9.readthedocs.io/en/latest/chapter6.html#catalog-zones

• Knot (>=3.0) https://www.knot-dns.cz/docs/3.0/html/configuration.html#catalog-zones

• NSD https://github.com/IETF-Hackathon/NSDCatZ

• PowerDNS https://github.com/PowerDNS/powercatz/

除了提高配置的性能和弹性之外，支持 catalog zones 还可以使 Designate 支持其他后端实现作为辅助 DNS 服务器，而无需专用驱动程序。

API 变更

无

Central 变更

1. Pool 对象（以及可能适配器）需要更新，以包含创建 catalog zone 所需的新池设置。有关这些设置的详细信息，请参阅 其他更改 部分。

2. Central 必须更新，以便在关联池中的区域被创建、更新或删除时，增加池 catalog zone 序列号。它还必须向受影响池中的名称服务器触发 NOTIFY。

3. Central 和/或 worker 必须更新，以便如果池配置了 catalog zone，则不要直接在后端 DNS 服务器上创建区域。

Storage 变更

1. 区域数据库模式需要更新，以添加一种新的“类型” CATALOG，以指示该区域是 catalog zone。

2. 现有的区域“版本”字段可用于跟踪 catalog zone “Schema Version”，这需要在区域的 TXT 记录中存在。根据此规范，版本必须为“2”。

3. catalog zone 不会关联 tenant_id。

4. 需要创建一个新的存储查询，将区域 SOA 和 NS 记录与目录的区域 PTR 记录列表合并。

   1. 为目录返回的区域记录将使用区域 ID 作为目录中区域 PTR 记录的“唯一 ID”。

5. Storage create_pool 和 update_pool 需要更新，以便在 pools.yaml 中包含适当的设置时，为池创建 catalog zone。有关这些设置的详细信息，请参阅 其他更改 部分。

6. Storage create_pool 和 update_pool 需要更新，以便在 pools.yaml “catalog_zone_tsig_key” 设置中提供一个时，在数据库中创建或更新 catalog zone TSIG 密钥记录。

7. Storage create_pool 和 update_pool 需要更新，以便在现有的 pool_attributes 表中捕获 catalog zone 属性。有关这些设置的详细信息，请参阅 其他更改 部分。

其他变更

1. 接下来需要扩展池定义，以添加一个可选的“catalog_zone”部分。

   1. 将在“catalog_zone”父项下添加一个“catalog_zone_fqdn”键/值。如果指定了“catalog_zone”，这将是一个必需字段。它将被验证，以确保它是一个有效的完全限定域名 (fqdn)。

   2. 将在“catalog_zone”父项下添加一个“catalog_zone_refresh”键/值。这是一个可选设置，如果未指定该参数，将使用默认值 60（秒）。此值将被验证，范围在 0 到 2147483647 之间，与其他区域一样。

   3. 将在“catalog_zone”父项下添加一个“catalog_zone_tsig_key”键/值。此设置是可选的，但在该功能的文档中强烈推荐。它将以与 API 中 TSIG 密钥验证相同的方式进行验证。

   4. 将在“catalog_zone”父项下添加一个“catalog_zone_tsig_algorithm”键/值。如果指定了“catalog_zone_tsig_key”，则必须指定此设置。它将以与 API 中 TSIG 算法验证相同的方式进行验证。

2. 必须创建文档来设置 catalog zone。

   1. 它必须包含安全警告和有关将 TSIG 密钥添加到 catalog zone 的指南。

3. 当通过 pools.yaml 池创建创建 catalog zone 时，将只为该区域创建一个 NS 记录。它必须包含“invalid.” 作为 NSDNAME，如 catalog zone 规范中所建议。

4. catalog zone SOA 记录字段：RETRY 和 EXPIRE 将以其他 Designate 区域定义的方式定义。

5. 必须更新测试以涵盖此新功能。

   1. 这应该包括验证非管理员用户无法查看 catalog zone 的测试。

6. 必须为该功能创建一个发布说明。

其他说明

1. 此规范不包括在 catalog zone 中创建“masters”记录。此扩展似乎尚未最终确定，并且它当前不支持替代端口号。这可以在将来添加。

2. 此规范不包括允许后端驱动程序配置后端 DNS 服务器上的 catalog zone。这可以在将来添加。

3. catalog zone TSIG 密钥包含在 pools.yaml 中，而不是通过 API 创建，以确保区域尽快受到保护，并促进未来可能自动在后端 DNS 服务器上创建 catalog zone 消费者的补丁。

替代方案

Designate worker 管理后端名称服务器上的区域的当前机制是实现“catalog zones”的主要替代方案。例如：对于 BIND，rndc 区域管理；对于 PowerDNS，HTTP API。

提供允许后端首先拉取其区域列表的方式，为显式配置后端及其驱动程序提供了替代或补充。

虽然有 Designate API 可用于获取区域数据以进行其他配置后端的方式，但 catalog zone 提供了一个通用且一致的接口，可以通过 AXFR 将此数据提供给各种 DNS 服务器。

提供 catalog zone 没有真正的替代方案，因为它是一种不同的数据模型和协议，然后由 Designate 提供。

实现

负责人

主要负责人

Christian Rohmann https://launchpad.net/~christian-rohmann

IRC 昵称

crohmann

里程碑

工作项

依赖项

升级影响