判断DNS放大攻击的流量特征与上游过滤方式，关键是看流量是否像大量 DNS 响应涌向受害地址，而不是只盯着总带宽。此类攻击利用伪造的源地址向解析器发送小请求，让较大的响应发往被伪造的地址；因此受害端通常看到的是入站响应，而不是对应的查询请求。
先从四类流量迹象识别
- 方向与端口：入站 UDP 流量骤增，源端口常为 53，目的端口可能分散在多个高位端口。目的端口分散本身不能作为定性依据，但与突发流量同时出现时值得排查。
- 包长与速率不匹配：小型查询可触发较大的应答，受害端可能看到数百字节至数千字节的数据包，带宽与包速率也可能同步上升。DNSSEC、记录内容及路径上的分片情况都会影响响应大小，不能用单一包长阈值判定。
- 来源分散：源地址可能来自许多互不相关的网络，地址看似是解析器，实际可能被伪造。仅按某个源地址封禁，往往拦不住持续变化的流量。
- 协议特征变化：流量常集中于 UDP，响应中可能出现较大的 DNS 记录或 DNSSEC 数据。对比平时的目的地址、包长分布和每秒包数，比单看总字节数更容易发现异常。
这些迹象应结合业务基线判断。公共解析服务的正常响应同样可能来自 53 端口；如果只按端口封禁，可能误伤合法查询和权威解析业务。
过滤优先放在上游，但要分清位置
攻击源网络：阻止伪造源地址
最有效的源头措施是源地址验证：网络运营方在用户流量进入网络时，检查源地址是否属于该用户可使用的地址范围，并丢弃明显不可能从该接口发出的数据包。这能减少伪造查询离开网络，但需要由接入网络或云服务商在边界配置，受害者通常不能单方面替所有来源完成此操作。
受害者上游：按流量特征限流或清洗
联系承载线路的运营方或流量清洗服务，提供攻击开始时间、受影响地址、协议、端口、包长分布和流量变化。请其在更靠近入口的位置实施临时过滤。若服务只提供固定规则，可先对明显异常的 UDP 流量限速；若能识别状态和 DNS 响应特征，则优先定向清洗，减少对合法 UDP 服务的影响。
- 从 NetFlow、sFlow 或防火墙统计中确认入站协议、源端口、目的端口、包速率和主要来源网络，并与攻击前基线比较。
- 确认受影响业务是否需要对公网提供 UDP 服务；列出必须保留的目的地址与端口，避免直接封掉全部 UDP 或所有源端口 53 的流量。
- 把样本统计和时间范围交给上游，先请求短时、可回滚的定向过滤或清洗，再观察误拦截、业务可达性及流量是否转移。
- 攻击缓解后撤销临时规则，复核告警和日志，并要求自有递归解析器限制不必要的公网递归服务，降低其被滥用的风险。
过滤策略的取舍
限速部署快，适合流量未压垮链路且规则能区分业务的情况，但阈值过低会丢失合法 DNS 响应。按特征清洗能减少对正常服务的影响，不过需要上游具备相应分析能力。若链路已经饱和，源站本地防火墙再精细也无法腾出入口带宽，应优先让运营商在上游处理；黑洞路由能快速保护其他网络资源，却会同时切断被牵引地址的正常访问，只适合作为最后手段。
还应检查自有解析器是否为开放递归解析器：递归服务通常只应面向授权网络或用户开放。源端口随机化可改善查询的不可预测性，但不能代替源地址验证，也无法单独消除放大风险。总体而言，DNS放大攻击的流量特征与上游过滤方式需要配合使用：先凭端口、包长和速率识别，再由最靠近流量入口的一方实施有边界、可回滚的过滤。
常见问题
看到大量 UDP/53 流量，就能确认是攻击吗？
不能。合法 DNS 响应也使用该端口；还要结合流量突增、响应大小、目标端口分布和业务基线判断。
为什么不直接封锁所有源端口 53 的数据包？
这种做法可能阻断合法解析流量。应先确认本地业务依赖，再由上游按受影响目标和异常特征定向限速或清洗。
过滤应先找解析器还是线路运营商？
若自有解析器被滥用，应修正递归访问控制；若大量流量正压向受害地址，则同时联系承载线路运营商，优先在链路入口过滤。