别再等待“零号病人”: DNS安全为什么要走向前置防御
网络安全行业长期以来习惯了一种节奏：攻击发生，受害者提交样本，安全团队提取特征，再把规则分发出去。这个办法并没有失效，但它有一个绕不开的前提——总要有人先中招。
生成式AI把这个问题放大了。钓鱼邮件可以针对收件人的岗位和业务场景临时生成，社工对话可以持续数周，恶意代码、域名和跳转链路也能快速更换。过去能够在多家企业重复捕获的攻击样本，如今可能只为一个目标使用一次。
如果每次攻击都换一张面孔，继续等待“零号病人”提供样本，显然会越来越被动。安全团队需要在恶意代码落地之前，寻找攻击者不那么容易绕开的环节。DNS正是其中之一。
一、AI改变的是成本和速度，不是攻击链
AI让钓鱼、深度伪造和自动化社工看上去焕然一新，但攻击链并没有凭空消失。攻击者仍要准备域名和服务器，把受害者引向钓鱼页面或恶意载荷；终端仍要完成域名解析，才能建立C2连接；窃取的数据也要通过某种通信路径送出去。
变化主要发生在规模和速度上。攻击者能够批量注册、快速轮换域名，让一个域名只服务于一次活动、一个地区，甚至一个目标。它还没来得及成为业内熟知的IOC，就已经完成任务并被丢弃。
Infoblox《2025 DNS威胁态势报告》基于其每天分析的700多亿次DNS查询指出：在一年内观察到的1.008亿个新域名中，25.1%被归类为恶意或可疑；更值得注意的是，95%的威胁相关域名只在一个客户环境中出现过。[1]
这里的95%并不是说“95%的域名都是一次性域名”，而是说大多数威胁域名缺少跨客户重复出现的机会。等它在多个环境中暴露、积累足够证据再处置，往往已经错过了最好的阻断时间。
二、为什么DNS是把防线前移的关键位置？
DNS不是一个孤立的网络组件。员工访问网站、终端连接SaaS、应用调用API、恶意程序连接C2，通常都要先把域名解析为IP地址。
DNS的价值首先在于位置。它通常发生在建立连接、下载载荷和传出数据之前；无论设备在园区、数据中心、云上还是家中办公，都离不开名称解析。更重要的是，恶意代码可以不断变形，攻击者却仍要注册域名、配置解析、部署服务器并维护C2或跳转网络。这些准备动作会留下可供分析的基础设施线索。
Protective DNS（保护性DNS）就是利用这个位置，把DNS从单纯的解析服务变成策略执行点：它不仅回答域名指向哪里，还要判断这个目的地是否应该被访问，并在连接建立之前处置恶意、可疑或违反策略的请求。
美国CISA已经面向联邦机构提供Protective DNS服务，用于阻止用户和系统连接已知或疑似恶意域名，并支持本地设备、漫游设备以及与SSE平台的集成。[2] 英国NCSC自2017年开始运营PDNS；其2024年度回顾显示，该服务累计处理超过2.5万亿次站点请求，阻止了对150万个恶意域名的访问。[3]
2026年3月发布的NIST SP 800-81 Rev.3则把Protective DNS、DNS日志、DNSSEC和加密DNS纳入企业DNS安全部署指南，并明确将DNS作为零信任和纵深防御的一部分。[4] Microsoft也在Windows 11中推进Zero Trust DNS，通过可信PDNS解析结果实施基于域名的出站访问控制。[5]
这些变化放在一起看，趋势已经很清楚：DNS正在从基础解析走向策略执行，从办公网走向远程终端、混合云和IoT/OT；安全团队关注的对象，也从已经落地的恶意载荷向域名注册、启用和基础设施聚类前移。与此同时，DNS事件开始进入防火墙、EDR、SASE、SIEM和SOAR的运营链路，而不是停留在网络团队的日志服务器里。
三、Infoblox的关键差异：盯住攻击者的基础设施
传统威胁情报经常从已经发生的攻击中提取恶意域名、IP、文件哈希和行为特征。Infoblox采用的核心思路不同：利用DNS遥测、数据科学、机器学习和威胁研究，观察攻击者如何注册域名、配置解析、搭建服务器、连接域名集群并逐步激活攻击基础设施。
换句话说，它不只追赶已经出现的恶意样本，还试图识别攻击者正在搭建的“发射阵地”。
在域名被武器化之前寻找线索
Infoblox Threat Intel持续分析大规模DNS事件，通过新观察域名、域名启用行为、解析关系、托管特征和攻击者基础设施聚类，发现尚未进入传统公共黑名单的风险域名。
Infoblox公开的产品与报告数据提供了一个观察尺度：
- 每天分析超过700亿次DNS事件；
- 跟踪超过20.4万个威胁活动集群；
- 在首次DNS查询之前识别并阻断82%的威胁；
- 平均比其他安全工具提前68.4天识别并阻断相关威胁；
- 在超过2000万个指标的口径下，误报率为0.0002%；
- 相比只依赖已知恶意行为的系统，可阻断5倍的高风险域名。[1] [6] [7]
这些数字来自Infoblox自身遥测、研究方法和产品测试，适合用来理解其技术路线和数据规模，不能直接当作每家企业的效果承诺。真正落地时，仍应通过检测模式和现网试点验证覆盖率与误报情况。
一个DNS控制点，覆盖三个攻击阶段
Infoblox Threat Defense可以在多个攻击阶段发挥作用：
- 用户点击之前或解析时：阻止访问钓鱼、仿冒、恶意广告跳转、恶意软件分发及其他高风险域名；
- 恶意软件落地之后：阻断终端通过DNS寻找C2服务器，切断远程控制和后续载荷下载；
- 数据外传阶段：识别DNS隧道、异常编码查询和可疑高频通信，降低攻击者利用DNS绕过传统出口控制的风险。
这里容易产生一个误解：既然DNS能在多个阶段阻断威胁，是不是可以少部署一些终端或边界安全产品？答案是否定的。终端安全观察进程和行为，防火墙控制连接与边界，DNS安全负责名称解析和攻击基础设施层。三者看到的是不同侧面，DNS安全的作用是把控制位置向前移，而不是取代后面的防线。
防火墙之外，还有品牌和客户
企业面临的风险并不都发生在自己的网络中。仿冒官网、近似域名、虚假活动页面、钓鱼二维码和品牌冒用，往往托管在境外或第三方平台上。内部防火墙即使阻断了员工访问，也无法自动消除客户、合作伙伴和公众面对的风险。
Infoblox的外部风险与域名缓解能力，可用于发现近似域名和外部仿冒资产，再通过证据收集、通知注册商或托管商等流程推动下架。2026年Infoblox完成对Axur的收购后，又把外部数字风险发现、自动下架与DNS层阻断接到了一起。[8] 对企业来说，这意味着处置目标不再只是“让内部员工打不开”，还包括尽快清除互联网上的仿冒入口。
DNS策略不能只留在总部机房
DNS安全的价值取决于覆盖范围。如果策略只覆盖总部网络，却看不到远程用户、公有云工作负载或分支机构，攻击者仍可从盲区建立连接。
Infoblox以DDI和Threat Defense为基础，把DNS、DHCP、IPAM、资产可见性和安全策略扩展到本地、分支、远程与多云环境。Google Cloud在2025年宣布由Infoblox提供威胁情报能力的DNS Armor，为Google Cloud工作负载提供云原生的恶意活动检测。[9] 这类合作说明，Protective DNS正在进入云平台，而不再只是部署在出口处的一台独立设备。
四、企业得到的，不只是“多拦截几个域名”
企业评估DNS安全，不能只看威胁库里有多少条记录。更实际的问题是：它能否降低一次攻击变成事故的概率，能否帮助业务少停一会儿，也能否让安全团队少花时间追逐噪声。
恶意域名如果在用户访问、载荷下载或C2连接时就被阻断，攻击者进入加密、横向移动和数据窃取阶段的机会自然会减少。企业避免的并非一条告警，而可能是停产、停服、赎金、数据泄露通知以及后续的品牌损失。
业务连续性也不只是“DNS服务器不能宕机”。一方面，关键解析服务需要高可用；另一方面，正常运行的DNS也不能持续把用户送往危险目的地。将DDI、DNS基础设施保护与Threat Defense结合，才同时覆盖了服务可用和访问安全。
对SOC而言，DNS记录还回答了几个调查中经常出现的问题：哪台设备、在什么时间、尝试访问哪个域名？如果这些记录能够关联资产、用户、DHCP租约和其他安全告警，分析人员会更快确认受影响设备和攻击阶段。威胁在DNS层被挡住后，也不会继续触发下游设备上的一串重复告警。
此外，域名监测与下架保护的是企业外部的客户和合作伙伴；与SIEM、SOAR、EDR、NGFW、SASE和工单系统的集成，则让DNS情报可以复用现有安全投资。一个成熟的DNS安全项目，不应该再造一座告警孤岛。
五、企业应如何判断自己是否需要升级DNS安全？
下面这些问题，值得网络和安全团队坐在一起逐项核对。如果其中不少问题只能凭印象回答，DNS很可能还是企业安全体系中的盲区：
- 全网哪些终端、服务器和云工作负载没有经过企业可控的DNS解析？
- 是否能在首次访问时阻断新注册、高风险、仿冒或一次性恶意域名？
- 是否能够识别DGA、DNS隧道、C2和DNS数据外传？
- 远程办公、分支、IoT/OT和多云环境是否执行一致的DNS安全策略？
- DoH/DoT是被安全纳管，还是正在绕过企业策略和日志？
- DNS告警能否关联到真实设备、用户、IP地址和业务资产？
- 仿冒企业品牌的外部域名被发现后，是否有可跟踪的下架流程？
- DNS安全事件是否已经接入现有SIEM、SOAR和事件响应体系？
第一步未必是采购或替换。更稳妥的办法，是先做一次轻量化的DNS安全态势评估，弄清现有安全产品漏过了什么、哪些设备正在绕开企业DNS、是否存在隧道或数据外传迹象，以及DNS事件能否进入当前运营流程。
有了这组基线，再从检测模式、重点用户或云环境开始试点，调好策略后逐步扩大范围。验收时可以关注：
- 恶意及高风险域名首次查询阻断率；
- C2、DGA、DNS隧道和数据外传发现率；
- 每万次拦截的误报数量；
- DNS安全告警平均调查与处置时间；
- 接入企业DNS策略的终端和工作负载覆盖率；
- 仿冒域名发现至确认、阻断和下架的时间；
- 下游防火墙、EDR和SIEM告警量的变化。
结语：把时间抢在攻击发生之前
AI可以帮助攻击者不断换诱饵、换代码、换域名，却省不掉搭建和使用基础设施的过程。DNS安全要争取的，正是从域名注册、启用到真正发动攻击之间的这段时间。
Infoblox的特点也在这里：它不满足于维护一份恶意域名黑名单，而是借助大规模DNS遥测和预测性威胁情报，观察攻击基础设施从形成到激活的过程，再把结果用于解析阻断、C2控制、隧道检测和外部仿冒处置。
这不是要用DNS安全替代防火墙、EDR或SASE，而是给现有纵深防御增加一个更早的控制点。对企业来说，真正有价值的变化不是“又多了一套安全产品”，而是安全团队不必每次都等到下一个零号病人出现，才知道应该阻断什么。
如果企业正在评估DNS安全，真正困难的往往不是理解某一项产品功能，而是如何把DNS与现有网络架构、安全设备和运营流程接起来。哪些风险应该先验证，原有防火墙和终端安全如何联动，策略怎样上线才不影响业务，都需要结合现网判断。
数据口径与参考资料
- Infoblox,2025 DNS Threat Landscape Report：1.008亿新观察域名、25.1%恶意或可疑、95%仅见于单一客户环境、每天分析700多亿次DNS查询。
https://www.infoblox.com/news/news-events/press-releases/infoblox-unveils-2025-dns-threat-landscape-report-revealing-surge-in-ai-driven-threats-and-malicious-adtech/ - CISA,Protective DNS FAQ：美国联邦机构Protective DNS的定位、覆盖与集成方式。
https://www.cisa.gov/sites/default/files/2025-05/Approved CSSO-Protective DNS FAQ 2024.pdf - UK NCSC,Annual Review 2024：PDNS累计处理超过2.5万亿次请求并阻止访问150万个恶意域名。
https://www.ncsc.gov.uk/files/NCSC_Annual_Review_2024.pdf - NIST,SP 800-81 Rev.3: Secure Domain Name System (DNS) Deployment Guide, 2026。
https://csrc.nist.gov/pubs/sp/800/81/r3/final - Microsoft Learn,Zero Trust DNS。
https://learn.microsoft.com/zh-cn/windows/security/operating-system-security/network-security/zero-trust-dns/ - Infoblox,Preempt Ransomware and Other Advanced Threats：82%、68.4天、0.0002%及威胁集群等产品数据。
https://www.infoblox.com/solutions/ransomware/ - Infoblox,Threat Defense：5倍高风险域名阻断、威胁情报与生态集成等产品能力。
https://www.infoblox.com/products/threat-defense/ - Infoblox,Why Axur Marks a New Era for Preemptive Cybersecurity, 2026。
https://www.infoblox.com/blog/company/why-the-axur-acquisition-marks-a-turning-point-for-preemptive-security/ - Infoblox and Google Cloud,Cloud-Native Networking and Security Partnership, 2025。
https://www.infoblox.com/news/news-events/press-releases/infoblox-and-google-cloud-announce-partnership-to-deliver-cloud-native-networking-and-security-solutions-reducing-complexity-for-enterprise-customers/
注：本文中Infoblox产品效果数据来自其公开报告、产品页面及遥测口径。实际效果受网络覆盖、策略配置、授权范围、数据源和企业环境影响，应以现网评估及试点结果为准。