一、账单不会说谎，但会误导

月初看云解析账单，解析请求数比上月翻了几倍；或者自建递归 DNS 的监控曲线陡然抬头、负载告警。很多网络负责人的第一反应是"被攻击了"，第二反应是"要不要升套餐"——两个反应都为时过早。

解析量超量是一个"果"，原因横跨三个世界：有人在恶意利用你（滥用与攻击）、你的配置在制造放大（错误与缺陷）、或者业务真的在涨（正常增长）。三种原因的处理方式完全不同，升套餐只解决第三种。

本文按"先分清解析发生在哪一层 → 8 类原因对号入座 → 五步排查法 → 按因施策"的顺序展开，多数情况下半天内可以定位到具体原因。

二、先分清：超量的量发生在哪一层

层级	是什么	计费/负载关系	谁在"消耗"
权威解析	别人来问你：你的域名指向哪	云解析服务商按请求数计费，超量=账单涨	全世界任何向你的域名发起解析的客户端
递归解析	你替内网用户去问全世界	自建递归服务器负载、出口带宽	你自己的内网设备

排查第一步：确认涨的是"别人查你的域名"（权威侧），还是"你的设备在查别人"（递归侧）。两者原因集合几乎不重叠，方向错了后面全白费。

三、8 类原因对号入座

A. 恶意滥用类（权威侧高发）

1. 随机子域名查询攻击（DNS Water Torture）

请求量的主体是不存在的随机子域名（如 8f3k2j9d.你的域名.com），大量 NXDOMAIN 应答。目的：打瘫你的权威 DNS 或消耗按量计费额度。识别：NXDOMAIN 占比飙升、子域名随机无规律。

2. 子域名枚举与资产测绘

查询集中在常见前缀字典（mail.、vpn.、oa.、dev.），成功与失败都有。这是攻击前的资产侦察——枚举你的子域名找入口。识别：子域名呈现字典特征、来源分散但行为一致。

3. 域名被用作 DNS 隧道 / 数据中转

特定子域名超长（上百字符）、TXT 记录查询激增、或域名被大量无关来源高频查询。你的域名可能被恶意软件当作 C2 通信或数据外传的中转站（原理见本站《僵尸网络与 APT 如何利用 DNS 请求》一文）。识别：按子域名长度排序、按记录类型统计。

4. 被当作开放解析器滥用（递归侧）

递归 DNS 收到大量与内网业务无关的域名查询，来自外部来源——被利用做递归放大或隐藏真实查询者。识别：查询源不在内网网段、域名与业务无关。这条同时是安全隐患（会被封禁、进黑名单），必须优先处理。

B. 配置错误类（最容易被忽视，也最容易修）

5. TTL 设置过短或为 0

TTL 是各地缓存服务器保存解析结果的时长。TTL 设成 60 秒甚至 0，意味着全世界每次访问都要回来问一遍你——本该被缓存的 99% 的查询全部落在你的权威服务器和账单上。识别：对比"业务真实访问量"与"解析请求量"的比例。这是企业最常见也最冤枉的超量原因。

6. 解析链路配置错误造成循环或放大

CNAME 链过长或成环、NS 记录指向自己形成解析循环，都会让递归服务器负载陡增。特别要警惕通配符记录（*.domain.com）与随机子域名攻击的叠加：通配符让"随机子域名攻击"每发必中，从 NXDOMAIN（可缓存吸收）变成真实解析（无法缓存），攻击效果被自己的配置放大。

7. 监控与健康检查配置过度

多个监控探测点以极高频率全量解析全部域名、健康检查间隔秒级、每次检查绕过缓存强制解析。识别：日志里固定来源 IP、固定间隔、固定域名集合——特征非常明显。

C. 业务正常类

8. 真实业务增长或流量事件

活动推广、新业务上线、新办公点/新设备批量接入、邮件系统启用（邮件网关的反向解析与 SPF 查询会带来稳定增量）。识别：解析量增长与业务指标（UV、设备数、邮件量）同步，来源分布正常。

四、五步排查法（半天定位）

1. 分层：先确认涨在权威侧还是递归侧；
2. 看源：按来源 IP/网段聚合 Top 20——全网分散（攻击/正常增长）、固定内网段（自己设备）、还是外部固定来源（枚举/隧道）；
3. 看域名：按 QNAME 统计 Top 与 NXDOMAIN 占比——随机子域名、字典前缀、超长子域名单各自有鲜明指纹；
4. 看类型与应答码：TXT 激增指向隧道；NXDOMAIN 风暴指向水刑攻击或枚举；NOERROR 但解析链极长指向配置问题；
5. 对时间轴：把解析量曲线与业务曲线（UV、发布记录、监控变更）叠加——同涨是业务，无关突增是异常。

前提只有一个：DNS 日志开着。云解析服务商的控制台通常自带请求量分析（按子域名、来源运营商、地域分布）；自建递归记得开查询日志并留 90 天以上。

五、按因施策：每类原因的处置方案

原因	处置要点
随机子域名攻击（1）	限速与 RRL；对随机子域名模式设置拦截规则；升级服务商的查询防护；必要时临时降级通配符记录
子域名枚举（2）	无法阻止查询本身，重点改为减小信息暴露：下线不必要的公网解析记录、内网资产不进公网 DNS、对枚举源限速
DNS 隧道滥用（3）	按"8 类异常特征"检测定位，封禁相关子域与来源，排查是否有失陷主机在利用你的域名
开放解析器（4）	立即关闭对外递归，只服务内网网段；处置不及时会进滥用黑名单，连带影响邮件业务
TTL 过短（5）	常规记录 TTL 调整到 600–3600 秒；只有即将切换的记录才临时调低，切换完成后调回。这一项通常直接消掉大部分"超量"
配置循环/放大（6）	梳理 CNAME 链与 NS 指向，消除环；谨慎使用通配符记录，必须用时配好子域名拦截规则
监控过度（7）	降低探测频率至必要值、复用缓存、探测点收敛；监控的价值靠告警规则质量，不靠轮询密度
业务增长（8）	该升套餐升套餐、该扩容扩容——同时借机做一次 TTL 与缓存架构优化，把钱花在刀刃上

六、三个预防性建议

1. TTL 策略化：全公司统一 TTL 基线（如常规 3600、待切换 60），写进变更流程，避免"图省事设 0"；
2. 解析量月度基线：每月记录权威/递归两侧的请求量、NXDOMAIN 占比、TXT 占比三条基线，异常从"事后看账单"变成"当周告警"；
3. 递归出口收敛：内网只有指定递归服务器可以出公网解析——这一条同时解决开放解析器滥用、DNS 隧道审计、恶意域名管控三个问题，与《僵尸网络与 APT 如何利用 DNS 请求》一文的建议共用同一套架构。

七、常见问题（FAQ）

Q1：解析量涨了，怎么快速判断是不是被攻击？

看三样：NXDOMAIN 占比（风暴攻击会显著升高）、子域名是否随机化（水刑攻击特征）、来源是否与业务无关。三者都不异常，优先查 TTL 和监控配置，别急着买防护。

Q2：TTL 设多少合适？

常规记录 600–3600 秒。TTL 不是越短越"灵活"：越短意味着缓存越失效、权威服务器和账单压力越大。需要快速切换时，提前把目标记录 TTL 调低，等旧 TTL 过期后再改记录，切换完成即调回。

Q3：通配符记录（*.domain.com）有什么风险？

它会让"随机子域名攻击"从"查询不存在域名"（返回 NXDOMAIN，可被缓存吸收）变成"查询存在域名"（触发真实解析，无法缓存），攻击成本被你的配置大幅放大。非必要不用，用则必须配套限速与拦截。

Q4：云解析按量计费超额了，直接升级套餐行吗？

先排查再花钱。如果是 TTL 过短或监控误配置造成的，调配置就能降下来；如果确认是攻击，升套餐只是花钱扛流量，还需要配防护能力。账单翻倍时，多数企业最终定位到的是配置问题而非攻击。

Q5：怎么知道我的域名有没有被用于 DNS 隧道？

按子域名长度排序（超长即可疑）、统计 TXT 类型查询占比、看是否有与业务无关的高频查询来源。详细特征与应对见本站《僵尸网络与 APT 如何利用 DNS 请求》一文。

Q6：自建递归 DNS 被外部主机利用了怎么办？

立即关闭对外递归（只允许内网网段查询），然后到 Spamhaus 等黑名单平台查询自身 IP 是否已被列入，按平台流程申请移除。处置越晚，进黑名单和被封禁出口的风险越高。

Q7：解析量正常但解析慢，和"超量"是一回事吗？

不是。解析慢更多与递归链路长度、缓存命中率、权威服务器响应能力有关。先看缓存命中率：命中率低（TTL 过短或缓存配置不当）既会造成慢，也会造成量涨——两个症状可能同源。

Q8：日志没开，历史数据丢了，还能排查吗？

部分可以。云解析控制台通常保留近期的请求量分析与子域名排行；抓一段当前流量做实时分析也能定位大多数原因。但长期看，查询日志留存 90 天以上是必须补上的一课——没有日志的 DNS 运维等于盲飞。

关于墨者安全
墨者安全致力于安全防护、服务器高防、网络高防、ddos防护、cc防护、dns防护、防劫持、高防服务器、高防dns、网站防护等方面的服务，全网第一款指纹识别技术防火墙，自研的WAF指纹识别架构，提供任意CC和DDoS攻击防御