本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
别名记录¶
https://blueprints.launchpad.net/designate/+spec/alias-records
ALIAS 记录（又称 ANAME、根 CNAME、根域名重定向、区域顶点 CNAME）是 DNS 的一个相对较新的“补充”。这些伪资源记录 (RR) 用于绕过 DNS 协议中的限制，这些限制禁止在任何其他 RR 旁边存在 CNAME RR。这会阻止 DNS 的一些现代用法，例如，许多 CDN 或其他静态内容托管站点（如 GitHub Pages）将要求用户将例如“www.example.org.” CNAME 指向他们的前端负载均衡器。使用 CNAME 旨在确保提供商可以轻松地进行基础设施更改，而无需每个客户都同步其部署计划进行 DNS 更改。
由于这不是 DNS 协议中的真实功能，因此对 ALIAS RR 的支持必须完全在最终用户的权威 DNS 基础设施中实现。
问题描述¶
DNS RFC 不支持根域的 CNAME 记录集
example.com IN CNAME example.github.com
因此，DNS 后端对这种功能的支持并不广泛。
提议的变更¶
Designate 将通过 API 暴露一个新的“ALIAS”记录集类型；该记录集将定期扁平化为“A”或“AAAA”记录集，以便传播到 DNS 后端。此解决方案与后端无关，并符合 RFC 实现。
验收标准¶
最终用户可以在 API 中创建“ALIAS”记录集，并通过所有其他 API 请求（例如，获取记录集、导出区域、导入区域）查看该记录集
所有“ALIAS”记录都将扁平化为所有后端的“A/AAAA”记录集。
example.github.com 的 IP 更改将导致后端上可用扁平化“A”或“AAAA”记录集的 IP 地址更新。
操作员可以配置用于解析和扁平化 ALIAS 记录集的自定义缓存名称服务器。
操作员可以设置扁平化过程的轮询间隔。
注意
不建议与 CDN 实现一起使用。
API 变更¶
“visible”值（如下所述）设置为“mdns”的 RRSets 将在 API 中被过滤掉。
此外，ALIAS RRSets 在 V1 API 中不可见。相反，将包含一个动态生成的 TXT 记录，以指示 ALIAS 记录的存在，该记录只能通过 V2 API 进行编辑。
示例 ALIAS 记录集创建请求
POST /v2/zones/2150b1bf-dee2-4221-9d85-11f7886fb15f/recordsets HTTP/1.1
Host: 127.0.0.1:9001
Accept: application/json
Content-Type: application/json
{
"name" : "example.org.",
"description" : "This is an example ALIAS record set.",
"type" : "ALIAS",
"ttl" : 3600,
"records" : [
"example.github.com."
]
}
扁平化任务¶
用户可以触发“扁平化”ALIAS 记录的过程。例如，如果用户开始收到解析无法工作的错误消息，用户可以发出 API 请求以强制更新。
示例手动扁平化请求
POST /v2/zones/<zone_id>/recordsets/<recordset_id>/tasks/flatten HTTP/1.1
Host: 127.0.0.1:9001
Accept: application/json
请求体应为空。此外，建议用户相应地为此端点配置速率限制。此速率限制超出此规范的范围。
导出¶
当区域作为区域文件导出时，导出应包含两行，即注释掉的 ALIAS 记录和最新的 A 记录。
例如
; example.com. IN ALIAS example.org.
example.com. IN A 192.0.2.1
这允许用户拥有有效的区域文件进行导入，同时提供可见性，表明 A 记录是由 ALIAS 记录生成的。
Central 变更¶
Central 的 create 和 update RecordSet 方法将被更新，以调用 Zone Manager 服务上实现的新 RPC 方法，以便在创建/更新 ALIAS RRSets 时触发立即 ALIAS 扁平化。如果解析失败，该记录将被置于 ERROR 状态。
Central 的 delete RecordSet 方法将被更新，以删除相关的扁平化 A 和 AAAA RecordSets - 识别这些相关 RRSets 的机制在 Zone Manager Changes 中有详细说明。
此外，ALIAS RRSets 的处理方式将与 CNAME 类似。在 A 或 AAAA RecordSet 旁边放置 ALIAS RRSet 将是无效的。记录集放置验证将被更新以处理这种情况。
MiniDNS 更改¶
MiniDNS 将被更新为显示“visible”字段（如下所述）设置为“mdns”或“all”的 RRSets，确保不会尝试在 AXFRs 中包含不符合 RFC 的 RRSets。
Zone Manager 更改¶
首先，对于它管理的每个区域，designate-zone-manager 服务将查找与该区域关联的任何 ALIAS 记录集。区域管理器将然后发出成功的 A/AAAA DNS 查询以获取与 ALIAS 目标关联的 IP 地址。Designate 的数据库将被更新为“真实”值，并递增 SOA 序列号以触发向公共面向名称服务器的 AXFR。
如果此查询失败并且无法解析 ALIAS 目标，则 A/AAAA 记录将不会更新，并且 ALIAS RR 将被置于 STALE 状态。
ALIAS 记录扁平化的间隔将是可配置的，默认为 1800 秒（30 分钟）。
最后，将实现一个新的 RPC 方法，以触发特定区域的立即 ALIAS 扁平化，从而允许在第一个定期间隔之前使用新创建的 ALIAS RR。此 RPC 方法也将由 ALIAS RRset 扁平化任务端点利用。
Storage 变更¶
Recordsets：更新列“type”¶
在“type”中添加“ALIAS”。
Recordsets：新列¶
字段 |
类型 |
是否为空 |
键 |
默认值 |
额外信息 |
visible |
enum(‘all’, ‘api’, ‘mdns’) |
NO |
MUL |
‘all’ |
示例数据¶
对于上述描述的示例场景，相应的数据库值如下（为简洁起见省略了列）
Recordsets 表¶
id |
domain_id |
name |
tenant_id |
type |
visible |
1230 |
768 |
example.github.com. |
391 |
ALIAS |
‘api’ |
0100 |
768 |
example.org. |
391 |
A |
‘mdns’ |
Records 表¶
id |
recordset_id |
数据 |
managed |
managed_resource_type |
managed_resource_id |
3211 |
1230 |
example.org. |
0 |
NULL |
NULL |
3212 |
0100 |
192.168.1.10 |
1 |
ALIAS |
3211 |
替代方案¶
一些 DNS 后端支持扁平化过程（例如，PowerDNS）。另一种实现方法是创建一个名为“ALIAS”的新记录集类型，该类型与每个各自后端的实现集成。
实现¶
负责人
- 主要负责人
Eric Larson <eric.larson@rackspace.com>
里程碑
- 完成目标里程碑
Mitaka-1
工作项
实现隐藏 API 和 MiniDNS 中 RRSets 的支持
在 designate-zone-manager 服务中实现周期性 ALIAS 扁平化
更新 Central 的 CUD RecordSet 方法以支持 ALIAS
依赖项¶
无
