DNS在信息安全管理体系中长期被当成基础网络服务，但其控制深度往往低于认证要求。ISO 27001:2022将网络安全管理列为附录A的A.8.20控制项，网络服务安全列为A.8.21控制项，而DNS解析同时涉及两个控制域：既要保证解析服务可用，又要防止解析通道被滥用。攻击者利用DNS进行缓存投毒、隧道回连、数据外泄和DGA恶意域名通信时，传统基于IP的防火墙规则很难有效识别。因此，DNS控制措施需要形成覆盖权威服务器、递归服务器、客户端和出站流量的组合策略，并与ISO 27001风险评估、运行监视和审计过程直接挂钩。下面从条款映射、核心配置、监控检测和审计证据四个层面展开。
一、把DNS控制映射到ISO 27001条款
ISO 27001附录A的A.8.20要求组织对网络和网络设备实施恰当的安全管理，A.8.21则强调网络服务的安全机制需要覆盖服务级别和连接要求。DNS解析服务作为网络服务的核心组件，在风险评估中至少需要关注保密性、完整性和可用性三个维度。可用性风险表现为单点递归解析器故障导致整个办公网无法访问互联网；完整性风险表现为缓存投毒导致用户被重定向到钓鱼站点；保密性风险则与DNS隧道外传数据、DNS查询泄露内部域名结构有关。
在资产识别阶段，权威DNS服务器、递归解析器、转发器、域名注册账户和解析日志都应纳入资产台账。安全控制措施的选取需要与风险等级匹配。例如，面向互联网的权威服务器必须做区域数据签名和访问限制，而内网递归解析器则需要严格限制查询来源并禁用公开递归。ISO 27001不要求固定采用某一种技术，但要求控制措施可测量、可审计，并能通过运行记录证明其有效性。因此，DNS相关操作不能只停留在配置层面，还必须有日志、告警和定期复核证据。
对于已经运行多年的DNS架构，常见差距包括递归查询对所有内网用户开放、权威与递归功能混跑、解析日志只记录错误不记录查询、出站DNS流量完全放行。这些差距在认证审核时会被视为网络服务安全控制不完整。整改时应先根据网络区域划分DNS角色，再逐步叠加DNSSEC、TSIG、ACL和日志输出，避免一次性变更导致业务中断。
二、核心DNS控制措施：角色隔离、DNSSEC与访问限制
第一项基础控制是角色隔离。权威DNS服务器只提供自身管辖区域的解析数据，应关闭递归功能；递归解析器只允许内部客户端发起查询，对外不可见。这样即使递归解析器被恶意利用，也不会直接污染权威区域数据。BIND中可以通过以下配置实现递归来源限制和权威关闭递归。
// 权威服务器 named.conf 示例
options {
recursion no;
allow-query { any; };
allow-transfer { none; };
};
zone "ipipp.com" {
type master;
file "/etc/bind/db.ipipp.com";
allow-transfer { 192.168.10.20; };
};
递归解析器则只允许内网网段查询，并启用DNSSEC验证。配置中的allow-recursion和allow-query需要设置为内部地址段，不应包含外部接口地址。
// 递归解析器 named.conf 示例
acl internal_clients {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
};
options {
recursion yes;
allow-query { internal_clients; };
allow-recursion { internal_clients; };
dnssec-validation auto;
version none;
};
第二项控制是DNSSEC。给权威区域启用DNSSEC的意义不仅是防止递归解析器接受伪造应答，还能为后续部署DANE、SSHFP等记录提供信任基础。启用DNSSEC需生成KSK和ZSK，对区域签名，然后将DS记录提交给上级注册商。签名后需要定期轮换ZSK，并通过监控系统检测签名有效期，避免区域过期变成重大安全事件。以下命令展示了生成签名密钥的基本流程。
# 生成KSK dnssec-keygen -a RSASHA256 -b 2048 -n ZONE -f KSK ipipp.com # 生成ZSK dnssec-keygen -a RSASHA256 -b 1024 -n ZONE ipipp.com # 将公钥加入区域文件并签署 dnssec-signzone -S -o ipipp.com db.ipipp.com
第三项控制是访问控制。DNS管理接口通常使用rndc或Web管理面板，需要限制来源IP并使用强认证。TSIG事务签名可以保护主从服务器之间的区域传送，防止未授权服务器拉取完整区域数据。对于Windows DNS服务器，则应通过安全策略限制动态更新，只允许域内计算机更新自身记录，同时禁用非安全动态更新。控制目标是让DNS服务的每一种交互都能回答谁在访问、访问了什么、变更是否授权。
三、DNS日志监控与隧道检测
没有日志的DNS安全控制无法通过ISO 27001的运行监视要求。应在递归解析器上启用查询日志，记录客户端IP、查询域名、查询类型、返回码和时间。对于流量较大的企业，可以使用dnstap或流式日志输出替代纯文本日志，避免磁盘性能瓶颈。日志至少需要保留六个月到一年，具体时限应根据组织的日志管理策略和合规要求确定。
logging {
channel dns_query_file {
file "/var/log/named/query.log" versions 5 size 500m;
severity info;
print-time yes;
print-category yes;
};
category queries { dns_query_file; };
};
基于查询日志可以识别典型的DNS隧道特征：高频TXT或NULL查询、单个查询域名长度异常、子域名数量过多、相同域名前缀带有Base64编码字符串、NXDOMAIN响应比例突然升高、以及从未出现过的随机字符域名。DGA恶意域名往往表现为单个客户端在短时间内请求大量不存在的域名，且域名结构与正常访问习惯显著不同。可以设置规则对每个客户端每分钟NXDOMAIN数量、唯一域名数量、平均域名长度进行统计，超过阈值则触发告警。
出站DNS过滤是另一个重要控制点。建议企业只允许经过批准的递归解析器访问外部DNS，其他主机的UDP 53出站流量全部阻断。递归解析器可配置转发或RPZ策略，使用威胁情报域名黑名单拦截已知恶意域名。RPZ的好处是可以直接集成到解析流程中，对客户端透明，不需要在每台终端部署额外代理。如果使用防火墙做DNS过滤，需要特别留意基于IP的阻断对CDN和泛域名场景的误伤，必要时结合TLS指纹或SNI信息做辅助判断。
四、审计证据准备与PDCA闭环
ISO 27001认证审核时，DNS控制项通常会查看配置基线文件、变更工单、日志保留策略、监控告警记录和恢复演练报告。企业应提前准备一份DNS安全控制说明，列出权威服务器和递归解析器的角色、IP地址、软件版本、配置模板路径、DNSSEC密钥管理方式和日志存储位置。每一次DNS配置变更应通过正式变更管理流程审批，并在变更记录中注明风险影响和回退方案。
从PDCA角度，规划阶段需要完成DNS风险评估，明确控制目标；执行阶段部署角色隔离、DNSSEC签名、ACL限制和日志输出；检查阶段通过月度审计和模拟攻击验证控制有效性，例如用内部测试域名验证是否能够被递归解析器正确处理；改进阶段根据发现的风险调整配置，例如缩短日志保留时间策略、增加新的黑名单源或优化告警阈值。只有形成这样的闭环，DNS安全才不会是审核前临时补出的静态配置。