DNS层面DDoS防护使用DNS响应限速和递归查询限制

DNS作为互联网的根基服务，其脆弱性在DDoS攻击面前被无限放大。攻击者早已不满足于简单的带宽消耗，针对DNS服务器的查询洪水、放大攻击以及递归投毒变种，能够轻易瘫痪一台看似配置强大的解析器。在DNS层面构筑防线，不能仅依赖上游清洗，本地策略的精细化配置才是决定生死的分水岭。其中，DNS响应限速（Response Rate Limiting, RRL）和递归查询限制是两项最直接、成本最低且效果立竿见影的硬核技术。它们不是花哨的概念，而是直接作用于服务器处理逻辑的闸门。

很多运维人员误以为部署了Anycast或购买了高防IP就可以高枕无忧，但现实是，针对特定域名的随机前缀攻击（如伪随机子域名攻击）或针对递归服务器的反射放大，往往绕过流量型防护，直接耗尽CPU和内存资源。这类攻击利用的是协议逻辑，而非单纯的带宽压制。因此，解决问题的钥匙必须插在DNS软件自身的锁孔里。我们要做的，是在BIND、PowerDNS、Knot DNS等主流软件中，像外科手术一样精准地切断异常流量，同时确保正常用户解析不受影响。

DNS响应限速并非简单的“每秒只回几个包”，它是一套基于令牌桶算法的智能判别系统。其核心逻辑在于区分“正常重复查询”与“攻击诱导的重复响应”。当攻击者伪造源IP向递归服务器发送大量针对同一域名的查询时，服务器会产生等量的响应包涌向受害者，这就是典型的反射放大。RRL技术会在响应出口处设立关卡，它记录下每一个响应包的分类特征，主要包括：源IP地址、查询域名、查询类型以及响应码。如果同一个分类下的响应在短时间内被频繁触发，系统就会判定为异常，并开始丢弃或截断响应。

以BIND的RRL实现为例，它允许管理员定义几个关键参数：responses-per-second（每秒允许的响应数）、window（统计时间窗口）以及slip（截断率）。这里有一个极易被忽视的误区：很多人把responses-per-second设得极低，企图一刀切死攻击，但这会误伤合法的递归请求。真正合理的策略是结合slip参数，slip设为2意味着每两次限速触发中，有一次会返回一个截断响应（TC=1），迫使合法的递归客户端通过TCP重试，而伪造源的攻击者由于无法完成TCP握手自然被淘汰。这种“TCP强制升级”策略，是利用协议特性进行的优雅反击。

在BIND的配置视图或全局选项中，嵌入RRL逻辑的代码块非常简洁，但背后的数学逻辑需要严谨推演。假设一台递归服务器在常态下的UDP响应速率约为5000 qps，而攻击发生时瞬间飙升至50000 qps。我们不应直接限制到5000，因为攻击流量中往往夹杂着真实请求。一个经验法则是在基础速率上浮20%-30%作为硬限，但配合slip机制放行合法TCP升级。

配置片段如下：

options {
    rate-limit {
        responses-per-second 10;
        window 5;
        slip 2;
        log-only no;
        exempt-clients { 192.168.1.0/24; };
    };
};

这里responses-per-second设为10是针对单一分类（如同一域名和类型）的，而非全局限速。window设为5秒意味着如果5秒内同一分类响应超过50个，即触发动作。slip 2保证了50%的截断响应率。特别需要注意的是exempt-clients，必须将你的上游ISP递归接口、监控探针以及内部白名单网段排除在外，否则限速会引发内部告警风暴。此外，log-only参数在调试阶段极其重要，先设为yes观察日志中“rate limit dropped”的数量，确认无误后再开启实际拦截，这是防止误伤业务的标准操作流程。

如果说响应限速是管住了“出”，那么递归查询限制就是管住了“入”。攻击者最恶毒的手段之一是利用随机前缀域名洪水（如12345.example.com）攻击递归服务器。由于这些域名在缓存中不存在，服务器必须一次次向权威服务器发起迭代查询，瞬间将并发递归连接耗尽，导致正常用户无法解析任何新域名。这就是典型的NXDOMAIN洪水或伪随机子域名攻击。递归查询限制就是给这台“引擎”装上转速限制器。

递归限制包含两个维度：一是限制单个客户端IP发起的递归查询速率，二是限制服务器全局的递归并发数。很多新手只配了前者而忽略了后者，结果攻击者利用大量肉鸡低频率查询，照样撑爆了服务器的递归栈。在BIND中，fetches-per-server和fetches-per-zone参数控制着对上游权威的查询速率，而clients-per-query则限制了等待同一个查询结果的客户端数量。更先进的方案是利用recursing-clients限制全局同时进行递归的客户端总数。

仅仅限制递归数量还不够，必须针对递归内容进行智能过滤。对于伪随机子域名攻击，最有效的办法是强制启用DNSSEC验证下的负缓存。当攻击者查询不存在的子域名时，权威服务器返回的NSEC或NSEC3记录证明了该名称不存在，递归服务器应严格遵守TTL进行负缓存。但攻击者往往会绕过这一点，不断查询不同的随机串。此时，我们需要引入“灰名单”机制或利用Response Policy Zone (RPZ) 动态标记。

在PowerDNS Recursor中，配置参数更加直观。例如，设置max-negative-ttl可以强制延长不存在的记录的缓存时间，哪怕权威服务器给的TTL很短。更狠的一招是调整max-cache-entries和max-packetcache-entries，当缓存被污染或撑满时，旧条目会被驱逐，这反而加剧了递归压力。因此，在遭受攻击时，适当增大缓存容量并锁定负缓存，是比单纯限速更底层的防御。同时，配置recursive-client-query-rate-limiting，针对单个IP限制其每秒递归查询数，例如设为20，配合动态黑名单，一旦某IP触发限制立即通过iptables或rbldnsd封禁一段时间。

如果你运行的是权威DNS服务器，虽然没有递归查询，但响应限速同样至关重要，且配置逻辑有所不同。权威服务器主要防止被用作DNS放大攻击的反射器。攻击者会向你的权威服务器发送ANY类型的查询或大包查询，伪造源IP为受害者。此时，你的响应限速应主要针对“响应包大小异常”和“特定域名高频查询”进行分类限速。

在Knot DNS中，其Rate Limiting模块基于哈希表实现，可以精确限制对特定域名的查询速率。更关键的是，权威服务器应强制实施最小化响应策略，拒绝不必要的ANY查询，或者对ANY查询返回空响应或截断。结合edns-client-subnet信息（尽管存在隐私争议，但在防伪源攻击上有效），可以识别出伪造的地理位置异常。对于权威服务器，response-rate-limiting的窗口应设得更短，因为权威服务器的响应模式相对固定，任何突发都可能是攻击前兆。

DNS防护中最惨烈的事故不是没防住，而是把正常用户全干掉了。响应限速最大的陷阱在于大型NAT网络或公共DNS出口。例如，一个大型企业或学校可能共用几个出口IP，当内部有机器中毒发起大量查询时，RRL会无情地将这个出口IP的所有请求限速，导致整个机构无法上网。此时，单纯的IP限速是盲目的。我们需要引入DNS Cookie（RFC 7873）或利用EDNS0选项进行客户端识别，但在实际落地中，更常用的妥协方案是提高NAT出口的限速阈值，并结合白名单。

另一个陷阱是TCP协议的依赖。虽然我们利用slip强制客户端通过TCP重试来验证真实性，但如果服务器的TCP并发连接数没有相应调优，攻击者同样可以通过伪造SYN包耗尽TCP栈。因此，开启响应限速和递归限制的同时，必须配合操作系统的TCP参数优化，如增大tcp_max_syn_backlog、缩短tcp_synack_retries，并确保DNS软件有独立的线程池处理TCP查询。

静态的配置文件永远无法应对动态的攻击手法。硬核的DNS防护必须走向自动化。通过解析DNS软件输出的日志（如BIND的querylog），利用流式处理工具（如Go语言编写的DNS流量分析器）实时计算源IP的熵值、查询域名的基尼系数以及NXDOMAIN比率。当某个源IP的查询熵值突然降低（大量查询同一域名）或NXDOMAIN比率超过90%时，自动调用rndc命令或API动态将该IP加入临时黑名单，或将其递归权限降级。

这种闭环系统可以将响应限速从“被动限流”升级为“主动隔离”。例如，可以编写脚本监控BIND的统计通道（statistics-channel），一旦检测到递归客户端数量激增且命中率骤降，立即触发告警并自动将递归限制参数收紧20%。这种基于实时状态的自适应调整，才是DNS层面DDoS防护的终极形态。它不再依赖某个固定的阈值，而是让服务器像生物体一样，面对压力时自动收缩保护核心功能。

DNS响应限速和递归查询限制是两块基石，但只有将它们嵌入到自动化的、具备感知能力的防御链条中，才能真正抵御住那些精心构造的、试图从逻辑层面击垮解析服务的攻击。