适用场景哪些业务需要关注 DNS 劫持DNS 劫持的发生位置通常在递归解析链路、运营商 Local DNS 或用户侧路由器业务方并不总是能第一时间感知。当 API 调用异常、App 上报数据回源 IP 可疑或用户在特定地区无法访问时域名解析结果往往已经被污染。一个可重复执行的检测任务应该是用多个独立的权威解析通道去验证同一个域名。如果不同通道返回的结果存在明显差异就需要人工介入确认。这正是 DNS 劫持检测 API 的设计思路通过对比 5 大公共 DoHCloudflare / Google / AliDNS / DNSPod / OpenDNS对同一域名的解析结果给出是否被劫持的结论。典型使用场景包括线上域名周期性巡检比如每 5 分钟或每小时检查一次核心域名。新域名接入业务前进行一轮解析健康度摸底。用户反馈部分地区无法访问时快速判断是否与解析污染相关。与自己的权威解析结果做交叉比对发现异常的 Local DNS 缓存。接口能力边界它能判断什么不能判断什么在接入前需要明确该接口的检测逻辑它对比的是 DoH 服务商返回的解析结果集合。若 5 个 DoH 返回的 IP 集合一致判定为低风险若多源结果不一致判定为高风险。需要理解的两点边界它不检测 DNSSEC 签名有效性。即使 DNSSEC 已部署DoH 响应中的 RRSIG 是否通过验证不在本接口返回字段内。它不定位劫持来源。接口只给出多源一致性的结论不区分是运营商劫持、路由器篡改还是权威解析配置错误。此外该接口的 QPS 为 5 次/秒这意味着它更适合低频巡检任务不适合作为高并发解析服务来调用。如果有大批量域名需要扫描应设计为队列分批执行。参数与鉴权Query 参数参数类型必填说明示例domainstring是待检测的域名不含https://前缀也不带路径baidu.com鉴权请求头需要携带X-API-Key。实际使用时应从环境变量或配置中心读取不要硬编码在代码仓库中。具体 Key 的获取方式以接口文档为准。使用 curl 发起一次检测以下命令将检测baidu.com是否被劫持curl -sS \ -X GET \ -H X-API-Key: $APIZERO_API_KEY \ https://v1.apizero.cn/api/dns-hijack?domainbaidu.com执行前确认环境变量APIZERO_API_KEY已正确设置。响应 JSON 中包含code、data和msg三个顶层字段。使用 Python 接入并解析结果以下代码展示了如何调用接口并将结果转换为便于后续处理的结构import os import json import urllib.request API_URL https://v1.apizero.cn/api/dns-hijack API_KEY os.environ[APIZERO_API_KEY] def check_dns_hijack(domain: str) - dict: req urllib.request.Request( f{API_URL}?domain{domain}, headers{X-API-Key: API_KEY}, ) with urllib.request.urlopen(req, timeout10) as resp: return json.loads(resp.read().decode(utf-8)) if __name__ __main__: result check_dns_hijack(baidu.com) print(json.dumps(result, ensure_asciiFalse, indent2))在实际项目中建议将超时时间、重试次数、日志记录封装为独立模块避免在业务代码中重复编写网络请求逻辑。返回字段解读成功响应的结构如下{ code: 0, data: { domain: baidu.com, is_hijacked: false, risk_level: low, summary: 5 个 DoH 服务商解析结果一致未检测到劫持迹象, unique_ips: [ 110.242.68.3, 110.242.68.4 ] }, msg: 成功 }字段类型说明codenumber业务状态码0表示请求成功data.domainstring传入的检测域名data.is_hijackedboolean最终结论是否判定为劫持data.risk_levelstring风险等级取值为low、medium或highdata.summarystring对人类可读的检测摘要data.unique_ipsstring[]去重后的解析结果 IP 集合msgstring说明信息is_hijacked为false且risk_level为low表示当前 5 个 DoH 服务商解析结果一致。若is_hijacked为true建议进一步核对unique_ips中是否存在不明 IP并检查当地网络环境。常见错误与排查思路1. 缺少 API Key 或 Key 无效请求返回 401 或code非 0。排查步骤检查环境变量是否已导出echo $APIZERO_API_KEY。确认 Key 是否有访问该接口的权限。2. 参数格式错误请求时传入了https://前缀或包含路径例如https://baidu.com/path。这可能导致校验失败或查询异常。域名参数应只保留baidu.com这种形式。3. 触发 QPS 限制批量检测时若循环中没有加延时可能返回限流错误。建议import time domains [a.com, b.com, c.com] for domain in domains: result check_dns_hijack(domain) print(domain, result[data][risk_level]) time.sleep(0.3) # 约 3 QPS留出余量4. 超时与重试DoH 服务商自身的响应速度会影响接口整体耗时。若上游 DoH 超时接口可能返回错误信息。调用方应设置合理的超时时间如 10 秒并对 5xx 错误做指数退避重试。工程化注意事项设计巡检任务时考虑状态变更而非单次结果单独一次的is_hijacked结论只有参考价值更有意义的是历史趋势。建议将每次检测结果写入时序数据库用于观察同一域名在不同时间段的风险等级变化。使用唯一 IP 数量辅助判断unique_ips的数组长度可以作为一个辅助指标。如果某域名历史上一直是 2 个 IP某次巡检突然变成 5 个陌生 IP即使is_hijacked字段为false也值得人工复核。关注 DoH 服务商的解析一致性接口只返回最终汇总数据不展示每家 DoH 的具体解析值。因此如果业务方需要细粒度定位“哪一家 DoH 返回了异常 IP”需要结合自建 DNS 监控或定期抓取各家 DoH 的解析日志来补充。避免将检测接口嵌入高并发路径QPS 5 次/秒的限制决定了该接口只适合低频任务。不要在用户请求的同步链路中调用否则并发稍有波动就可能被限流。建议的做法是用消息队列收集待检测域名。定时任务从队列中取域名按 200ms 间隔串行调用。检测结果写入结果表供前端或告警系统查询。与自建检测脚本的取舍自建多 DoH 对比脚本在技术上并不复杂但需要自行维护 DoH 服务商的接口变更、超时策略、结果聚合逻辑和告警规则。使用现成 API 的优势在于检测逻辑由服务端统一维护调用方只需关注业务告警。对于没有专职 DNS 运维团队的团队这种方式更节省人力。参考文档接口文档https://apizero.cn/aidocs/dns-hijack原始文档https://apizero.cn/aidocs/dns-hijack/raw.md
