01 引言
域名系统(DNS)就像是互联网的地址簿,通过将一个或多个复杂难记的IP地址映射到容易识别和记忆的域名上,便于人们通过简单的域名比如 bilibili.com 访问互联网资源。在此基础上,DNS 还提供了负载均衡等重要服务。是极为关键的互联网基础设施。
以 DNS 为基础的内网 DNS 服务则提供了一些额外的好处:
1. 私有域名
方便内网服务互联互通
外界无法感知和探测到,满足了安全性和隐私方面的需求
2. DNS 劫持
拦截特定公网域名到内网 ip,降低公网带宽和访问延迟。如某核心服务 A 早期只有公网域名,随着业务发展,内部非常多其他服务调用 A 服务,此时内部调用产生的公网带宽成本已非常高。而推动其他服务更换内网域名成本不低,DNS 劫持则能轻松帮我们解决问题。
拦截恶意公网域名,降低安全隐患
3. 特定业务逻辑支持
内部调用 API,方便管理与运维
主机名管理和私有ip反向解析支持
支持特定域转发
4. 极低的解析延迟以及极高的吞吐量
因此本文将分享 B 站内网 DNS 服务建设相关实践。
02 架构演进
考虑到基础设施的稳定性,我们选择了知名度最高、普及范围最广的 DNS 实现 BIND9 作为 DNS Server。
在介绍架构之前,我们简单了解一下内网 DNS Server 中最常用的两种角色:
权威 Name Server
权威 Name Server 是实际持有并负责特定域资源记录的服务器,通常是解析器查找 IP 地址过程中的最后一步,拥有这些域的最终解释权。
权威 Name Server 在软件层的实现又可以分为主权威和从权威。对 DNS 查询来说主从权威完成是对等的,但是它在软件架构上提供了必要的故障灾备和横向扩容能力。
解析器(Caching Name Servers)
解析器通常是 DNS 查询中的第一站,处理用户的递归查询,并提供完整的答案。当收到请求时,解析器向DNS层次结构发出一个或多个迭代查询。在获得一个完整的答案(或一个错误)后,解析器将答案传递给用户,并将记录放入其缓存。用户对同一查询的后续请求将从解析器的缓存中得到回答,直到缓存记录的TTL过期,那时它将从缓存中被刷新;请求相同信息的下一个用户查询将导致对DNS层次结构的一系列新的查询。
解析器在不同的使用场景下常被称为各种令人困惑的名字,如缓存名称服务器、递归名称服务器、转发解析器、区域解析器和全面服务解析器等。
典型域名解析过程图:
1. 第一代 DNS 架构
B 站内网 DNS 服务早期第一代架构相对比较简单,核心关注高可用和稳定性,采用了主从模式,保障每个核心 IDC 有独立的从权威集群,通过 VIP 提供负载均衡,并通过 VIP 健康检查机制自动踢掉故障节点。同时各 IDC 机房内网互通,互为备份。
随着业务的发展,在高 QPS 场景中,主从权威 Zone 配置同步时存在解析时长突增,响应时延不稳定的问题。其次从权威的可扩展性也相对较弱。因此我们衍生出第二代 DNS 架构。
2. 第二代 DNS 架构
第二代 DNS 架构主要引入了多级缓存。
首先是引入了 Caching Name Servers,可扩展性得到了非常大的提升。同时也避免了权威节点配置/Zone变更带来的抖动。
其次是针对大数据、AI 等 QPS 极高的业务,引入 NSCD 作为 Client 缓存服务。既降低了响应延迟也提高了整体服务吞吐。
在此基础上,第二代架构还对 BIND9 Server 进行了升级和优化。BIND9 虽然支持多线程,但是在我们早期使用的 9.11 版本中,最高只能利用 400% 的 CPU,单实例 QPS 峰值在 10 万左右,为了提高服务器利用率,我们进行了单机多实例部署,但这也给运维带来了复杂度。在新的版本中,因为支持 reuseport、日志写缓存等新特性,对性能有非常大提升,单实例可以充分利用多核 CPU,在生产环境压测中单机 QPS 超过 150 万,因此我们也在线上进行了升级。
03 DNS 服务监控建设
DNS 服务监控告警主要分为三个层面:
1. 主机层
2. 业务层
3. Client 端
1. 主机层
主机层通常都会有 CPU、内存、网络、磁盘等资源的使用率、饱和度、错误监控告警。这里主要强调两点容易忽略或者对 DNS 服务比较重要的监控告警。
单核CPU/单网卡的使用率告警
现代 IT 服务架构中,从交换机到服务器网卡到服务器CPU,各个路径几乎都是多 Pipeline 负载均衡,因为错误配置或使用不当,可能会出现单核CPU/单网卡负载不均衡,引发服务异常的情况。
网络层面
1. 网卡收发包异常告警
2. TCP、UDP errors 告警
2. 业务层
BIND 内部指标采集
BIND 通过 statistics-channels 暴露了丰富的内部监控指标。早期我们通过 bind_exporter 采集,但是遇到两个比较明显的问题:一是 bind_exporter 默认会采集 /xml/v3/tasks 数据,这个路径下的数据即无用,又会严重影响解析时延;二是部分比较重要的指标 bind_exporter 没有采集。因此我们重新开发了采集程序。
Zone 记录值变化率/变化量告警
监测每个 Zone 的记录值变化量,防止内部 API 等异常变更导致大量记录值被删除。
BIND 错误日志监控告警
错误日志能更详细的反应 BIND 内部的异常情况,帮助我们及时排障。
3. Client 端探测告警
服务内部的监控并不总能真实反映用户到服务端的访问质量,因此我们在各个机房部署多个探针,模拟真实用户请求,多Zone多域名高频率监测每个 Server 的可用性、内容正确性和响应时延。Client 探针多次帮助我们及时发现网络设备小概率BUG、网络拥塞等业务方还感知不到的异常。
同时增加 Client 到 Server 的网络 Ping 时延和丢包率监控,在异常时做辅助判断。
这里补充一点,公网公共 DNS 也并不是稳定的,需要对其进行监测和告警。目前我们的实践经验是阿里云公共 DNS 稳定性相对更好一些。
04 踩坑经验
一个复杂系统总会有很多细节是我们在使用初期没能了解或掌握的,因此这里分享一些我们踩过的坑帮助你走好自己的路。同时推荐阅读《常见DNS操作和配置错误》[3]。
1. 保障 UDP 和 TCP 端口用户皆可访问
通常 DNS 默认使用 UDP 传输,同时在 rfc 中约定 DNS 使用 UDP 传输时,包体需小于等于 512 字节(不包括 IP 或 UDP 包头)。512 字节的限制在大部分场景都能满足需求,但当记录值过长超过限制时,Server 端需置 TC 位为 1,告知 Client 响应被截断。Client 在收到 TC 位为 1 的响应时,需用 TCP 重新发起请求。这就要求 TCP 端口也必须可达。
根据以上信息,也额外提醒大家,在选域名时应尽量短小,记录值尽量简单,以便提高解析速度。
2. Zone 配置变更后必须增大序列号
主从权威的同步过程如下:
① 主节点 Zone 配置变更,向从节点发送 NOTIFY 通知
② 从节点返回 NOTIFY Respons,并向主节点发起 SOA 查询
③ 主节点返回 SOA Respons
④ 从节点对比 SOA Respons 中的序列号是否比自身序列号大,仅当 SOA Respons 序列号大于自身序列号时才发起 Zone transfer request,并利用 TCP 53 端口进行数据传输
因此 Zone 配置变更后必须增大序列号,否则会导致主从节点数据不一致。
3. 慎用 rndc flush 刷新全量缓存
线上难免会遇到刷新缓存的需求,如果直接用 rndc flush 刷新全量缓存,在有客户端缓存如 NSCD 的情况下,在每一次客户端缓存过期的时间都可能会产生极高的 QPS 。
因此,尽量使用 flushname 或 flushtree 来刷新指定域名或 Zone。
4. 慎用泛域名解析
泛域名解析是指利用通配符 * 将所有的子域名都指向相同的解析记录,实现灵活配置。然而当某个子域名需要独立配置时,容易忽略泛域名的配置,引发故障。
举个例子(以真实故障为蓝本),方便大家理解:
① 业务上线初期为了方便配置使用泛域名解析: *.example.com CNAME xxxcdn.com
② 发展一段时间后 a.example.com 有了新需求,需要加个 TXT 做验证
③ 运维同学添加解析 a.example.com TXT xxx
④ 此时因为 a.example.com 只有 TXT 记录,没有 A/AAAA 或 CNAME,直接导致 a 站点无法访问
05 结语
基础设施服务具有杠杆作用,良好的基础设施服务可以帮助业务提高效率,降低开发运维成本。作为基础设施的一部分内网 DNS 亦是如此。我们始终以业务需求为基础,不断演进与迭代,致力于提供稳定、可靠、易用、好用的服务。