GitHub 是如何改进自身的 DNS 架构的

据 GitHub 高级架构工程师 Joe Williams撰文介绍，过去数年中，GitHub 一直使用的是一个简单的DNS 架构。虽然它也能适合工作需求，但现在GitHub 已迁移到一个能更好地支持自身规模的新架构。

Williams 提及，很多应用对 DNS 的解析性能或可用性十分敏感，这是 GitHub 采用新的 DNS 处理模型的一个原因。DNS 会导致用户性能降级，甚至无法提供服务。当使用原有的 DNS 架构进行配置和代码更改时，这个问题亟待解决。此外，工程师也难以识别一些故障的导致根源，他们唯一能使用的工具是 tcpdump。除了对上述问题的改进，GitHub 工程师还瞄准于：

• 增加内部域（Zone）和外部域配置的灵活性。除非做特殊的配置，否则内部域对外是不可见的。同时，从内网的内部就可以访问外部域。
• 改进缓存节点（Cache）和授权节点（Authority）间的角色隔离。
• 支持基于部署和基于 API 的工作流，实现更改的自动化。
• 避免任何外部依赖，改进可靠性。

在 GitHub 设计的架构中，有三种类型的节点：

• 缓存节点。它部署于各数据中心内，负责向应用提供实时数据，使应用无需跨数据中心。
• 边缘节点（Edge）。它是各数据中心本地的授权节点，行使网关职责，处理来自缓存节点的请求，并负责域传送（Zone Transfer）。
• 授权节点。它是 DNS 主服务器，管理来自边缘节点的域交换，并提供创建、修改或删除记录的 HTTP API。

日志功能是 GitHub 新 DNS 架构的另一个改进。GitHub 工程师根据自身需求，选择了对缓存节点使用 Unbound ，边缘节点使用 NSD ，授权节点使用 PowerDNS 。

前面提到，外部域（github.com）可从内部域（github.net）访问，不需要与外部 DNS 提供商通信。这是使用 Unbound 实现的。此外，Unbound 还支持在内部 DNS 失败时对外部网络的访问。

在 Williams 的帖子中，还给出了更多的技术细节，值得全面一读。

查看英文原文： How GitHub Revamped its DNS Infrastructure