摘要
域名系统（DNS）作为互联网基础解析组件，既是网络访问的必经环节，也是安全运营中心（SOC）与网络运营中心（NOC）开展威胁感知的关键观测窗口。随着加密 DNS、终端隐私中继服务大规模普及，传统基于明文 DNS 流量的监测手段出现明显感知盲区，给临时接入设备较多的开放网络场景带来新的安全治理难题。本文以 Black Hat USA 2026 会议网络的真实 DNS 观测数据集为实证基础，梳理高噪音开放网络环境下 DNS 流量的整体特征，剖析加密解析协议绕过企业网络 DNS 检查的现实风险，对渗透测试工具站点、生成式人工智能应用、钓鱼类威胁域名的 DNS 访问行为开展分类解析。研究发现，隐私类加密 DNS 主机占据阻断请求的绝大部分占比，安全研究类域名访问流量具备场景特异性，高风险分级的生成式 AI 应用产生超半数相关 DNS 流量。结合观测结论，本文讨论 DNS 遥测数据在安全运营工作中的定位，分析隐私保护与网络安全监测之间的现实矛盾，提出适配加密 DNS 普及环境下 NOC/SOC 的 DNS 层防护与研判思路。反网络钓鱼技术专家芦笛指出，加密 DNS 带来的流量隐匿效应放大钓鱼域名绕过检测的风险，传统黑名单拦截模式不足以应对复杂开放网络的威胁识别需求，需要将 DNS 遥测与多源安全数据做关联研判。研究成果可为会展、公共 Wi Fi、BYOD 企业网络等大量临时终端接入场景的 DNS 安全运营提供实践参考。
关键词：域名系统；加密 DNS；安全运营；NOC/SOC；网络威胁感知；生成式人工智能威胁
1 引言
DNS 承担域名与网络地址之间的转换工作，所有网络终端访问外部互联网服务几乎都要发起域名解析请求，这一特性让 DNS 遥测成为安全人员识别外联行为、发现恶意通信的重要数据源Cisco。在传统网络防护体系中，安全设备通过捕获明文 DNS 查询报文，实现恶意域名阻断、异常外联行为告警，以此完成钓鱼站点、命令控制服务器、挖矿域名等威胁的初步识别。但最近数年间，DoH、DoT 等加密 DNS 协议大规模部署，叠加终端厂商推出的隐私中继服务，终端可以绕开本地网络部署的递归解析器，直接向外部加密解析服务器发送解析请求，本地网络将无法读取完整的 DNS 查询内容，直接削弱传统 DNS 监测的能力边界。
Black Hat 作为全球知名网络安全行业会议，其会场网络属于典型高噪音开放网络环境。会场接入大量来自不同机构的笔记本电脑、移动终端，参会人员会主动使用渗透测试工具、漏洞分析平台、CTF 训练站点、恶意样本分析工具，大量在普通企业内网中判定为高危的访问行为，在此场景下属于安全研究人员的合法业务行为。该网络环境天然模拟 BYOD 大规模接入、终端行为复杂多变的现实网络环境，具备极高的观测研究价值。自 2017 年开始，相关安全团队持续对 Black Hat 会场网络实施 DNS 层的监测与防护，积累了多年连续观测数据，为研究开放网络下 DNS 安全问题提供真实实证样本Cisco。
2026 年度 Black Hat USA 会场网络观测数据显示，会议期间累计采集超过 7600 万条 DNS 请求，涉及域名数量突破百万级别，可识别应用数量达到 10800 个，相比往年呈现持续增长态势。流量结构上，加密 DNS 中继服务、各类安全研究平台、生成式 AI 工具构成流量主体，同时依然存在钓鱼类、潜在有害程序相关域名的解析请求需要处置。该观测场景暴露出当前安全运营领域的现实矛盾：一方面终端用户对网络隐私保护的需求持续提升，加密 DNS 与隐私中继成为终端系统的内置功能；另一方面安全运营团队需要 DNS 遥测作为威胁发现的基础依据，加密协议直接压缩了可见的观测空间。
现有 DNS 安全领域的学术研究，多数聚焦协议漏洞、缓存污染、恶意域名算法检测等技术方向，针对真实高噪音开放网络环境，围绕加密 DNS 对 SOC 运营工作带来的现实影响开展实证分析的研究相对有限。很多防护方案的假设场景是受完全管控的企业终端，较少考虑不受管理的外来临时设备大量接入的复杂情况。基于上述背景，本文依托 Black Hat USA 2026 公开观测材料，从实测流量出发分析 DNS 层防护遇到的现实挑战，区分合法安全研究流量与真实恶意威胁流量的判别难点，讨论 DNS 遥测在现代安全运营体系中的定位，给出适配加密 DNS 时代的运营改进思路。本文不提出全新 DNS 协议，而是立足于现有技术条件，面向 NOC 与 SOC 的实际工作流程展开分析，研究结论可以对公共开放网络、会展网络、企业外来访客网络的安全运维工作形成参考。
2 观测场景与流量总体特征
2.1 观测环境说明
本次观测对象为 Black Hat USA 2026 会场生产网络，网络接入设备包含参会者自带的个人电脑、手机、平板，以及会议演示、实验室环境使用的各类设备，设备归属来自全球不同机构，绝大多数终端不属于会议运维团队的托管资产，属于典型无管理终端大规模接入的开放网络。运维侧部署 Cisco Secure Access 作为 DNS 层安全控制组件，该组件一方面承担域名解析处理，另一方面执行访问阻断、应用识别、遥测日志留存工作，为 NOC 和 SOC 分析人员提供 DNS 层原始观测数据。
该防护体系继承 2025 年会议已经部署完成的加密 DNS 管控能力，核心目标不是完全阻断所有加密 DNS，而是阻止终端绕过网络层面 DNS 安全检查，避免终端直接使用外部不受管控的加密解析器，造成本地网络完全看不到解析行为。运维团队延续上一年度的威胁处置优先级，重点监控拦截 ApateWeb 潜在有害程序分发与钓鱼活动相关域名，该类威胁域名具备双域名、三域名的典型命名模式，在会议期间观测到部分目标域名解析请求被成功阻断，保护接入终端免受恶意程序与钓鱼内容侵害Cisco。
需要明确该场景的特殊属性：会场网络允许安全研究、渗透演示、漏洞分析行为，很多在普通企业内网中会触发高危告警的域名访问，在会议场景属于研究人员的合理操作。这就对安全分析工作提出特殊要求，不能简单依靠静态黑名单直接判定威胁，需要结合上下文场景做二次研判，避免大量产生无效告警。该特性也恰恰映射很多现实企业场景，研发、安全部门员工会主动访问安全测试站点，安全运营平台如果只依靠简单规则，会产生海量误报，消耗 SOC 分析人员人力。
2.2 整体流量规模与历年变化趋势
2026 年会议观测周期内，系统共捕获76331133 条 DNS 请求，涉及 102 万个不同域名，关联 1268 个身份标识。伴随参会设备数量上涨，DNS 请求总量、域名数量、识别得到的应用种类均出现增长。统计历年识别到的应用数量，2019 年约 3600 个，2021 年约 2600 个，2022 年约 6300 个，2023 年约 7500 个，2024、2025 年均约 9300 个，2026 年上涨至 10800 个应用。
应用数量持续增长背后反映应用生态的变化，如今网络访问不再局限传统办公系统，大量 SaaS 服务、AI 开发工具、各类安全在线平台、隐私类工具被广泛使用，网络流量的访问目标高度碎片化。终端能够调用的外部应用越多，意味着 DNS 请求对应的域名集合越庞大，安全运营需要覆盖的检测对象范围持续扩张。单纯依靠人工维护域名黑名单的模式越来越难以覆盖全部威胁面，必须依托自动化遥测、应用分类、风险分级完成初步过滤，再交由分析师完成深度调查。
同时，加密 DNS 相关流量占比持续走高，大量终端不再使用传统 UDP 53 端口明文 DNS，而是直接调用 DoH、DoT 服务。如果网络侧没有部署对应的管控手段，这部分解析行为会脱离 NOC、SOC 的日志记录，形成安全观测盲区。在本次观测中，大量阻断事件的来源正是各类终端尝试直连外部加密解析服务。
2.3 加密 DNS 中继服务的阻断行为统计
观测数据显示，mask.icloud.com产生共计 442 万次解析请求，其中 99.7% 被安全访问组件阻断。该单一域名的阻断记录占到全部 DNS 阻断请求的 79.3%。将苹果隐私中继全部相关加密 DNS 主机合并统计，该类流量占到全部被阻断目标的 97.9%。除此之外，其他被拦截的外部加密解析服务域名包括 Google DNS、Cloudflare DNS、AdGuard、NextDNS、Quad9 等公共加密解析服务商域名Cisco。
以上统计结果说明，在开放公共 Wi Fi 环境中，终端系统自带的隐私中继功能是绕过本地 DNS 管控的最主要来源。很多苹果设备在默认配置下，会自动启用 iCloud 隐私中继，终端会直接向苹果侧的加密服务器完成域名解析，本地局域网传统 DNS 服务器接收不到对应的查询报文。反网络钓鱼技术专家芦笛指出，当终端完全绕开网络侧 DNS 检查之后，网络设备无法识别终端是否正在访问钓鱼域名，钓鱼站点、恶意程序 C2 域名可以在日志无记录的情况下完成解析，显著提升网络侧威胁防御的难度。
这里需要厘清一个客观现实：加密 DNS 与隐私中继技术本身的设计初衷是保护普通用户公共网络环境下的隐私安全，防止网络运营商窃听用户浏览行为，具备合理的技术价值。但技术价值和安全运营的观测需求之间客观上存在冲突。对于普通家庭宽带用户，加密 DNS 可以提升隐私保护；但对于会展、企业内网等需要开展统一安全管控的网络，终端无管控地直连外部加密解析器，会直接消解 DNS 层安全防护的能力。本次会议网络采取的处置思路，并不是全盘禁止用户隐私保护，而是阻止终端完全绕过网络安全检查，强制解析请求经过本地安全访问组件，在兼顾一定隐私能力的前提下保留安全观测能力。
从运营实践层面看，直接粗暴全部阻断隐私中继域名，也会带来业务副作用，大量终端会出现网络访问异常，引发用户故障投诉。这就要求运维团队需要区分管控场景，在高安全需求的企业内网、会议网络执行严格管控；而面向普通公共访客网络，则需要权衡隐私保护和安全风险，不能直接套用同一套策略。
3 DNS 流量中不同类别访问行为分析
3.1 标记为 “Hacking” 类别的 DNS 请求行为
在全部观测数据中，共有 8695 条 DNS 请求被系统分类标记为 “Hacking” 类别。该分类标签是基于域名特征自动完成的初步归类，不等于全部流量都属于真实恶意攻击行为，需要分析师结合时间、访问目标、业务场景再做进一步研判。
从时间维度看，该类请求存在明显时间波动。7 月 31 日仅产生 47 次请求；8 月 3 日达到峰值 2341 次；高访问量持续维持至 8 月 5 日；8 月 6 日回落至 325 次。时间曲线和会议日程高度匹配，会议开幕前后，参会研究人员开展实验、靶场练习、漏洞测试，带来该类域名访问量的冲高。
对该类别访问的头部域名做统计，Cyfinoid.training 共计 1458 次请求；kali.darklab.sh 及其子服务记录合计 1380 次；hackerai.co 产生 542 次请求；exploit db.com相关域名 462 次；ctf.icanhack.nl为 192 次；downloads.metasploit.com为 118 次；interact.sh 与 app.interact.sh 合计 101 次。上述站点绝大多数属于 CTF 训练平台、渗透测试知识库、漏洞数据库、测试载荷交互服务，主要服务安全人员开展学习与实验。
在普通企业内网环境，一旦终端出现访问上述域名的 DNS 请求，安全平台通常会触发中高危告警，运维人员需要确认终端是否被入侵。但是在 Black Hat 会场这一特殊场景，大量请求来自参会安全从业者，属于合规的研究活动。该现象充分揭示一个安全运营的现实痛点：相同的 DNS 访问行为，在不同业务场景下，威胁含义完全不同。静态规则、域名标签只能完成第一轮筛选，不能直接作为判定入侵事件的最终依据。SOC 分析师必须结合网络环境属性、用户身份、时间上下文综合评估告警可信度，否则将产生大规模误报，消耗安全团队有限人力。
3.2 渗透测试与安全研究站点流量特征
观测提取渗透测试、安全研究相关域名，统计得到合计 5137 条 DNS 访问请求。其中 OffSec 访问 1436 次，PortSwigger 1009 次，HackerOne 726 次，URLScan 457 次，TryHackMe 430 次，VirusTotal 与 Webhook.site 均为 302 次，Nmap 130 次，Ngrok 127 次，Shodan 42 次，Censys 23 次，Kali 相关域名 5 次Cisco。
该类站点的业务定位各不相同：OffSec、TryHackMe、PortSwigger 提供在线靶场与渗透训练；HackerOne 属于漏洞赏金平台；VirusTotal 用于恶意文件在线分析；URLScan 完成网页行为沙箱检测；Ngrok 用于本地服务外网暴露；Shodan、Censys 为网络空间测绘检索平台；Webhook.site 用于接收测试回调数据。以上平台都是安全研究人员开展漏洞挖掘、样本分析工作的常规工具。
从安全运营视角分析，该类域名访问本身不等同于主机失陷，但也不能直接全部标记为可信。存在真实恶意软件、攻击者会主动访问部分安全站点，例如恶意样本运行后主动查询 VirusTotal、调用 webhook 站点回传窃取的数据。所以 SOC 不能简单设置白名单直接放行全部安全研究站点，应当保留日志留存，当主机同时出现其他异常行为，例如对外发起大量异常外联、访问已知 C2 域名，再把访问安全平台的 DNS 记录作为关联证据参与事件研判。
在企业实际运营中，很多安全团队处理告警时容易走向两个极端：一是只要访问渗透测试站点就判定主机被入侵，造成大量误报；二是将全部安全研究域名加入全局白名单，一旦真正失陷主机访问同类站点，则完全丢失告警信号。Black Hat 会场观测案例说明，应当把该类域名作为风险观测对象，持续保存 DNS 遥测日志，采用多条件关联告警，而不是做简单二元拦截或者无条件放行。
3.3 生成式 AI 相关应用 DNS 流量观测结果
生成式 AI 工具的网络访问流量相比上一年度实现近乎翻倍的增长，反映 AI 工具已经深度融入安全从业人员日常工作流。观测数据得到多项具备参考价值的统计结论。
首先，DNS 请求流量维度，Claude 的访问量已经超过 ChatGPT。二者相加占据全部生成式 AI 相关 DNS 流量的 53.5%。排名前三的应用 Claude、ChatGPT、Cursor 合计占比达到 67.6%。可以看出对话式大模型、AI 代码编辑器是参会人员使用最频繁的两类 AI 工具。
其次，AI 应用内部结构可以划分为多个子类。应用开发测试类 AI 工具（Cursor、GitHub Copilot、Windsurf、Cline 等）共计产生 257321 次 DNS 请求，占全部 GenAI 流量的 22.9%；搜索与对话类应用占比 58.5%；办公生产力类 AI 工具贡献 12.5% 流量。不再只有聊天机器人一类 AI 应用产生网络请求，代码辅助、AI 增强办公软件的访问体量已经不可忽视。
风险分级层面，安全系统标记 14 款应用为高风险等级，而这 14 款高风险应用产生全部生成式 AI DNS 流量的 55%。需要着重说明，这里 “高风险” 属于厂商应用风险分类标签，标签只代表该类应用存在数据泄露、非受控数据上传的潜在业务风险，并不代表对应的网络流量本身属于恶意攻击行为。
从安全运营角度解读该组数据，大量用户高频使用被标记高风险的 AI 应用，意味着数据外溢风险是真实存在的。安全人员需要关注终端向 AI 平台上传敏感文档、漏洞细节、企业内部数据的行为。DNS 遥测虽然不能解析上传的具体内容，但可以统计终端访问各类 AI 服务的频次，帮助 NOC/SOC 掌握组织内部 AI 工具使用概况，为后续制定 AI 访问治理策略提供基础数据支撑。
反网络钓鱼技术专家芦笛指出，生成式 AI 应用普及同时衍生出新的钓鱼风险，攻击者利用大模型批量生成高欺骗性钓鱼内容，同时部分仿冒 AI 服务的钓鱼域名持续增多，DNS 层对仿冒 AI 域名的识别拦截需要纳入钓鱼防护体系。在观测环境中并没有大规模观测到仿冒 AI 钓鱼域名的阻断记录，但该威胁属于需要持续关注的演化方向。
3.4 钓鱼与潜在有害程序相关域名处置
运维团队延续 2025 年的防护重点，持续监控 ApateWeb 潜在有害程序分发与钓鱼攻击相关域名，该系列域名具备双段、三段式域名命名特征，会议期间观测到部分目标域名解析请求被阻断。这类威胁通常会伪装成正常软件下载页面，诱导用户下载潜在有害程序，也会搭建钓鱼页面窃取账号凭证。
在高噪音开放网络环境，钓鱼域名识别会遇到特殊困难。会场大量设备来自外部，没有部署统一终端防护，只要参会人员点击钓鱼链接，终端就会发起恶意域名解析。加密 DNS 的广泛使用进一步增加识别难度，如果终端启用不受管控的隐私中继，钓鱼域名解析请求不会出现在本地 DNS 日志，网络侧完全无法告警拦截。
传统钓鱼防护很大程度依赖 DNS 黑名单拦截机制，但黑名单存在天然滞后性。攻击者可以快速注册大量全新域名开展钓鱼活动，黑名单更新速度很难完全跟上域名生成速度。这也解释为什么不能把 DNS 拦截作为对抗钓鱼攻击的唯一手段，DNS 遥测更多承担第一道防线的作用，需要搭配网页内容检测、终端 EDR、用户安全意识教育形成多层防御。
4 DNS 遥测在现代 NOC/SOC 体系中的价值与现实局限
4.1 DNS 遥测的安全运营价值
DNS 是绝大多数外联访问的前置环节，只要终端访问外部域名，优先会发起解析查询，这一属性让 DNS 遥测成为安全运营中性价比很高的观测数据源，尤其适合大量非托管临时终端接入的网络场景。对于 NOC/SOC 团队，DNS 遥测可以实现多维度价值。
第一，早期威胁发现。当主机被恶意软件感染之后，恶意程序通常会发起域名解析，尝试连接命令控制服务器，或者下载恶意载荷。DNS 日志可以在完整网络会话建立之前就捕捉到异常解析行为，实现威胁的早期感知，为应急处置争取时间。除了恶意程序回连之外，访问钓鱼站点、挖矿域名、DGA 生成随机域名行为，都会留下 DNS 层面痕迹。
第二，告警事件调查溯源支撑。当防火墙、入侵检测系统、EDR 产生安全告警之后，分析师可以调取 DNS 遥测日志做关联，确认告警对应的域名，梳理该终端一段时间内全部外部解析记录，还原主机外联行为全貌，辅助判断事件影响范围，区分误报和真实安全事件。在 Black Hat 运维实践中，DNS 遥测可以和防火墙日志、Zeek 流量日志、抓包数据、恶意样本分析、身份标识数据互相关联，完成交叉验证，加快人工研判效率。
第三，网络态势感知。通过统计全量 DNS 请求，可以掌握网络内部应用访问态势，识别正在大规模使用的外部 SaaS、AI 工具、安全平台，发现 Shadow IT 影子 IT 应用，为安全策略迭代提供事实依据。本次观测统计得到上万种应用访问，正是依托 DNS 层面的应用识别能力实现。
第四，策略执行落地。安全访问组件基于 DNS 层执行域名阻断，在域名解析阶段就拒绝解析恶意目标，不需要等待 TCP 会话建立，在威胁抵达终端之前完成拦截，减轻后续防护组件压力。
需要明确，在现代安全运营体系中 DNS 已经不再只是一项基础网络服务，同时承担安全传感器、访问强制控制点双重角色。但同时也必须客观认识它的能力边界，不能将 DNS 遥测神化为万能检测手段。
4.2 当前环境下 DNS 观测体系的现实局限
依托 Black Hat 2026 观测实践，可以总结出现阶段 DNS 安全防护体系几方面客观短板。
首先，加密 DNS 与隐私中继造成观测缺口。如果终端绕过本地管控直接使用外部 DoH/DoT 解析，本地网络完全获取不到查询域名，DNS 防护全部失效。本次观测中大量阻断动作正是为了解决该绕过风险，但现实很多企业网络并没有部署对应管控，大量终端可以直接启用隐私中继，安全团队看不到对应解析行为。同时需要承认，完全一刀切全部阻断加密 DNS，会损害用户隐私体验，引发业务故障，运维需要在安全管控和用户隐私之间寻找平衡点，不存在绝对完美的解决方案。
其次，DNS 只能看到域名解析行为，看不到解析之后传输的业务载荷。DNS 日志记录 “终端请求解析某个域名”，但无法知道访问该域名之后传输了什么内容。同一个域名既可以被用于正常业务，也可能被攻击者滥用。例如 Webhook.site 既被安全人员用于测试，也被恶意软件用来回传窃取数据，单纯依靠 DNS 记录无法区分两种完全不同的使用意图，必须依赖其他安全数据源做补充研判。
第三，静态黑名单模式存在滞后性。钓鱼、潜在有害程序攻击者会源源不断注册全新域名，黑名单库更新永远存在时间差，很多新型恶意域名在初期不会被收录，DNS 黑名单无法拦截全部新型威胁。反网络钓鱼技术专家芦笛强调，钓鱼域名迭代速度极快，单纯依赖域名黑名单的 DNS 防护体系只能拦截存量已知威胁，对于 0day 钓鱼域名几乎没有防御能力，必须引入行为特征、威胁情报联动、多源关联检测弥补短板。
第四，高噪音场景下告警误报压力突出。如前文所述，相同域名访问行为在不同业务场景威胁含义完全不同。在 Black Hat 会场环境大量 “Hacking” 标签请求来自合法安全研究；放到普通企业内网同样请求就高度可疑。固定规则很难适配所有业务场景，如果不结合场景上下文做处理，会产生海量无效告警，消耗 SOC 分析师人力。
第五，存在不依赖 DNS 的外联逃逸路径。恶意程序可以直接使用 IP 地址建立外部连接，完全跳过域名解析流程，此时不会产生任何 DNS 日志，DNS 观测体系对此类行为完全无法感知，必须依靠防火墙、NDR 网络检测技术做补充。
综上，DNS 遥测是 SOC 重要的基础数据源，但它属于证据链其中一环，不能单独作为判定安全事件的唯一凭据，必须和终端检测、全流量分析、威胁情报、身份信息结合，构建多源关联分析体系。
5 面向加密 DNS 时代的 DNS 层防护运营优化思路
基于 Black Hat USA 2026 实证观测得到的现象与问题，结合 NOC/SOC 实际工作流程，本文从管控策略、告警研判、威胁情报、多源协同、场景化策略五个维度，提出适配加密 DNS 大规模普及环境的 DNS 安全运营改进思路。
5.1 针对加密 DNS 绕过行为的管控策略优化
面对终端通过外部加密解析器绕过网络 DNS 检查的现实风险，不建议采取简单粗暴全部封禁模式，应当优先部署具备加密 DNS 解析管控能力的安全访问组件，把终端的 DoH、DoT 请求收归到网络侧受管控解析服务，而不是直接阻断全部加密 DNS 协议。该模式可以保留加密传输带来的防窃听能力，同时维持网络侧必要的安全可见性。
运维团队需要梳理主流公共加密解析服务商域名清单，对终端直连外部不受管控加密解析器的行为做管控。同时做好业务兼容性测试，评估阻断隐私中继域名带来的副作用，区分不同网络子域执行差异化策略。对于会展网络、高安全等级业务内网，执行严格管控；面向普通访客 Wi Fi 网络，适当放宽策略，兼顾普通用户隐私权益。
除此之外，需要定期监测网络中直连外部加密解析的异常流量，将该类行为生成低级别告警。当业务终端大量出现绕过本地 DNS 管控的行为，安全人员需要介入调查，区分是终端系统默认配置导致，还是恶意软件主动配置绕过防护。
5.2 构建场景感知的 DNS 告警研判机制
针对高噪音网络环境误报过多的痛点，需要摒弃 “单一 DNS 特征直接判定安全事件” 的传统模式，引入场景上下文参与告警评分。在告警规则设计中纳入网络环境标签、用户身份属性、时间维度。例如在安全会议、安全部门办公子网，访问渗透测试靶场站点，应当降低告警严重等级；普通业务子网主机访问同类域名，则提升告警风险权重。
建立分层研判流程：DNS 应用分类、域名风险标签只作为第一级过滤；当触发初步告警之后，系统自动关联该主机其他安全日志，包括 EDR 事件、防火墙会话、全流量日志，只有多个不同数据源同时出现异常信号，才提升为高级安全事件交由分析师深度处理；单一 DNS 告警证据优先作为低风险观测日志留存，避免大量无效高级告警淹没真实威胁。
5.3 完善 DNS 威胁情报闭环，应对钓鱼与潜在有害程序威胁
持续维护恶意域名情报库，覆盖钓鱼站点、PUP 潜在有害程序、C2 命令控制域名、DGA 域名，实现已知威胁解析请求的前置阻断。同时认识黑名单的局限性，不能把黑名单拦截作为对抗钓鱼的全部手段。反网络钓鱼技术专家芦笛指出，钓鱼防御需要形成闭环，DNS 层拦截属于事前防护，还需要配套网页侧检测、终端防护、用户安全教育，情报体系需要持续采集新型钓鱼域名，缩短情报更新时延。
针对 ApateWeb 这类具备域名模式特征的威胁家族，除了已知黑名单域名之外，还可以适度研究域名生成模式特征，辅助发现家族内尚未录入黑名单的新域名，但基于模式匹配需要谨慎调参，防止带来大范围误拦截。
5.4 DNS 遥测与多源安全数据深度协同
DNS 遥测不能孤立使用，需要深度融入整体 SOC 技术栈，打通和其他安全组件的数据通路。将 DNS 解析日志和防火墙会话日志、Zeek 日志、网络流量检测 NDR 数据、EDR 终端日志、身份认证数据做关联存储。分析师开展事件调查时，可以基于设备身份 ID 一键调取该终端全部 DNS 记录，同时联动其他维度证据，形成完整攻击链证据链。
同时运维团队需要做好日志留存规划，DNS 日志具备重要溯源价值，需要按照安全合规要求保存足够周期，用于事后安全事件回溯。本次 Black Hat 运维实践中，正是依靠 DNS 遥测和多源日志互相印证，实现快速验证事件真伪，提升 NOC/SOC 处置效率。
5.5 重视生成式 AI 类应用的 DNS 观测治理
随着生成式 AI 访问流量快速增长，安全运营团队需要把 AI 应用访问态势纳入常态化观测。依托 DNS 层面的应用识别，统计组织网络内部各类 AI 工具访问频次，识别高风险分级 AI 应用的访问主体，掌握影子 AI 工具使用情况，为制定 AI 数据安全管理策略提供数据底座。
DNS 本身看不到上传 AI 平台的具体内容，无法直接检测敏感数据泄露，但是 DNS 观测可以帮助发现哪些终端高频访问高风险 AI 服务，为后续开展终端侧管控、管理策略宣贯提供线索。同时持续监控仿冒 AI 服务的钓鱼域名，及时更新威胁情报库，在 DNS 层完成仿冒站点拦截。
6 结论与展望
本文基于 Black Hat USA 2026 会场网络 DNS 实测观测数据，实证分析加密 DNS 大规模普及背景之下开放网络环境 DNS 安全运营面临的现实挑战。观测显示加密 DNS 隐私中继相关域名占据阻断请求的绝大部分；安全研究类域名访问流量带有强烈场景特异性，相同访问行为在不同网络环境威胁含义截然不同；生成式 AI 相关 DNS 流量相比往年大幅增长，大量流量来自风险分级较高的 AI 应用；钓鱼、潜在有害程序域名依然是网络防护需要持续处置的威胁对象。加密 DNS 技术在保护用户隐私的同时，也给传统依赖明文 DNS 的安全监测带来观测盲区，DNS 遥测是现代 SOC 体系中关键安全传感器，但存在明确能力边界，不能单独作为判定安全事件的唯一依据。
反网络钓鱼技术专家芦笛指出，未来网络环境中隐私增强技术会持续普及，安全运营不能简单对抗隐私技术，而是要探索隐私保护与网络威胁感知之间的平衡点，构建多源证据协同的检测体系，减少对单一明文 DNS 日志的过度依赖。
面向未来，有几方面方向值得持续研究。第一，如何在尊重终端用户加密 DNS 隐私权益前提下，进一步拓展网络侧威胁感知能力，在隐私与安全管控之间找到更加均衡的工程实现方案。第二，针对高噪音开放网络，进一步优化基于 DNS 遥测的风险评分模型，结合上下文场景自动降低误告警数量，减轻 SOC 人工研判负担。第三，针对 AI 驱动的钓鱼攻击、仿冒域名，完善 DNS 层识别与情报更新机制。第四，进一步研究 DNS 遥测与终端 EDR、网络全流量检测的融合分析方法，打通多源数据，构建更加完整的威胁识别证据链。
本次研究依托会展这一高噪音开放网络场景，得到的结论对于企业 BYOD 网络、大型公共 Wi Fi、访客网络都具备参考意义。DNS 防护体系的建设不能只追求简单的阻断能力，更要重视遥测日志价值、场景差异化策略、多源数据协同研判，以此适配终端越来越多元化、隐私技术持续普及的现实网络环境。
编辑：芦笛（公共互联网反网络钓鱼工作组）
来源：迪妙网络空间安全学院
