DNS是用户访问业务的第一跳，域名解析失败或变慢，用户感知到的就是“网站打不开”，哪怕后端服务器运行得再稳定也无济于事。因此，把DNS纳入SLA管理体系，明确定义一套可量化、可考核的DNS指标，是运维体系建设中不可缺失的一环。本文将从指标定义、阈值设定、采集方案三个层面，详细讲解如何在SLA框架下管理DNS服务质量。
一、SLA视角下的DNS核心指标定义
定义指标之前先要明确一个原则：SLA指标必须是可度量、可复现、无歧义的。一个常见的错误是把“DNS正常”简单等同于“服务器进程存活”，这远远不够。进程活着不代表能正确应答，能应答也不代表延迟达标。从SLA角度出发，DNS服务质量至少要覆盖正确性、及时性、容量三个维度。
正确性维度最核心的指标是解析成功率，计算公式为：解析成功率 = 正确应答次数 / 总查询次数 × 100%。这里的关键在于“正确应答”的判定口径必须写清楚：应答中包含期望的记录类型和记录值，且响应码为NOERROR或NXDOMAIN（NXDOMAIN本身是合法应答，要看业务上是否预期该域名不存在）。如果口径不清晰，不同的统计脚本可能给出完全不同的结果，SLA考核就失去了意义。
及时性维度的指标包括解析延迟和超时率。解析延迟通常统计P95、P99分位值而非平均值，因为DNS查询的长尾延迟对用户体验影响极大，平均值很容易掩盖问题。超时率的定义同样要明确超时阈值，业界常用500毫秒或1秒作为超时线，超过该时间未收到应答即记为一次超时。容量维度则关注QPS承载能力，即DNS服务在满足延迟SLA的前提下能处理的最大查询速率。
二、权威DNS与递归DNS的监控口径差异
很多团队在定义DNS指标时忽略了权威与递归的区别，导致监控数据和用户真实体验对不上。权威DNS是你自己运营、对外提供域名解析答案的服务器，它面对的客户端主要是运营商和公共DNS的递归服务器；而用户终端实际查询的是递归DNS，递归服务器会根据TTL缓存权威侧的答案。
监控权威DNS时，指标口径相对可控：你可以在解析服务前面部署探针，直接向权威服务器发起查询，统计成功率和延迟。而监控递归侧时，情况复杂得多。用户分布在不同的运营商网络，各地递归服务器的缓存状态、网络质量都不一样，单点探测无法代表整体。因此递归侧的SLA指标通常需要借助多地拨测，从多个地域、多个运营商网络发起真实域名解析，汇总得到全网成功率。
两个口径需要分开定义、分开考核。例如可以约定：权威侧解析成功率不低于99.99%，P95延迟低于50毫秒；递归侧全网解析成功率不低于99.9%，P95延迟低于200毫秒。递归侧指标天然包含缓存命中的成分，数值通常会好于权威侧直连探测，但如果递归侧指标劣化而权威侧正常，问题多半出在TTL设置不合理或跨网链路上。下面是一个用dig做多点探测并统计延迟的脚本示例：
#!/bin/bash
# 对权威DNS做解析探测，输出查询是否成功及耗时
TARGET_NS="ns1.example-ns.com"
DOMAIN="www.ipipp.com"
TIMEOUT="timeout 2"
total=0
success=0
for i in $(seq 1 100); do
start=$(date +%s%N)
result=$($TIMEOUT dig @$TARGET_NS $DOMAIN A +noall +answer +time=2 +tries=1 2>/dev/null)
end=$(date +%s%N)
if [ -n "$result" ]; then
success=$((success + 1))
echo "第 $i 次查询耗时 $(( (end - start) / 1000000 )) ms"
fi
total=$((total + 1))
done
echo "成功率: $(( success * 100 / total ))%"
三、TTL命中率与缓存相关指标的考量
TTL决定了解析结果在递归服务器上的缓存时长，直接影响故障切换速度和权威侧负载。在SLA指标体系中，可以引入缓存命中率这一指标：递归侧命中缓存直接返回答案的查询占总查询的比例。命中率越高，权威侧压力越小，用户侧延迟越低，但同时也意味着记录变更后全网生效的时间被拉长。
定义这个指标时要特别注意与故障演练联动。假设业务要求DNS切换必须在5分钟内全网生效，那么TTL就不应超过300秒；如果监控数据显示实际命中率偏低、TTL形同虚设，说明权威侧QPS被大量透传，需要评估是TTL设置过短还是递归侧不遵守TTL。此外，还应监控NXDOMAIN比例和SERVFAIL比例，前者突增通常意味着域名拼写错误或遭遇扫描，后者突增则往往指向权威侧异常或递归侧到权威链路故障，两者都应设置独立的告警阈值。
对于使用智能解析（按地域、运营商返回不同IP）的业务，还需要增加解析准确性指标：验证各地探测点拿到的IP是否属于该区域预期的地址池。这个指标经常被遗漏，一旦线路配置错误，用户会被调度到跨网线路，延迟翻倍但常规的成功率指标完全正常。
四、落地：指标采集、告警与SLA报表
指标定义清楚后，落地需要三件事：采集、告警、报表。采集层面，自建DNS（如BIND、CoreDNS）可以直接暴露内部计数器，CoreDNS配合Prometheus插件可以将查询计数、延迟分布直接输出为指标；BIND则可以通过statistics-channel获取统计JSON。外部拨测建议采用多地探针加统一汇聚的架构，探测数据写入时序数据库。
告警规则要与SLA等级挂钩。核心域名建议设置两级告警：成功率跌破99.95%触发P2告警，跌破99.9%或P99延迟超过1秒触发P1告警并自动启动应急预案。告警必须基于滑动窗口统计，比如最近5分钟的成功率，避免单次抖动引起误报。以下是一个基于Prometheus的告警规则示例：
groups:
- name: dns-sla-rules
rules:
- alert: DnsQuerySuccessRateLow
expr: |
sum(rate(dns_responses_total{rcode!="NOERROR"}[5m]))
/ sum(rate(dns_responses_total[5m])) > 0.001
for: 2m
labels:
severity: P1
annotations:
summary: "DNS解析失败率超过0.1%，已持续2分钟"
- alert: DnsLatencyHigh
expr: |
histogram_quantile(0.99,
sum(rate(dns_request_duration_seconds_bucket[5m])) by (le)
) > 1
for: 5m
labels:
severity: P2
annotations:
summary: "DNS解析P99延迟超过1秒"
报表层面，SLA报告应按月输出各域名的达标情况，统计不可用时长并折算成可用性百分比，与承诺值对比。一个实用的做法是把指标分成承诺指标和观测指标两类：承诺指标（成功率、P99延迟）写入SLA并参与考核，观测指标（缓存命中率、NXDOMAIN比例）用于趋势分析和容量规划。这样既保证了考核口径的严肃性，又不会让报表被过多的指标淹没。最后提醒一点，任何SLA指标定义都应附带清晰的测量方法文档，写明探测点位置、探测频率、超时阈值和判定规则，否则在故障复盘时，指标数字本身就会成为争议的焦点。