在财务系统的安全建设里，防火墙、数据库加密、访问控制通常是最受关注的部分，而DNS这个看似只负责域名解析的协议，往往成为审计检查中的薄弱环节。事实上，DNS通道被利用于数据外泄、域名劫持导致钓鱼页面替换登录入口等事件并不少见。对财务系统而言，DNS审计不仅是技术问题，更是合规硬性要求，本文详细梳理需要落实的关键内容。
一、财务系统为什么必须做DNS审计
财务系统处理的核心资产是资金和账务数据，攻击者一旦通过DNS隧道把数据分批带出内网，传统的防火墙流量审计很难发现，因为DNS查询本身是正常业务必需的流量。另外，财务人员每天访问的银行对账、税务申报、支付网关等站点都依赖域名解析，如果内部DNS被投毒或者客户端hosts被篡改，员工很可能在毫无察觉的情况下把U盾凭证提交到伪造站点。
从合规角度看，等保三级以及金融行业的监管规范都对网络日志留存提出了明确要求，DNS解析日志属于网络审计日志的一部分。多数监管要求日志留存不少于六个月，涉及核心交易链路的建议保留一年以上。审计检查时通常会问三个问题：能否查到某台主机在某个时间点解析过什么域名、能否证明解析记录未被篡改、异常解析有没有触发告警。回答不了这三个问题，DNS审计基本就是空白的。
二、DNS日志应该记录哪些字段
一条合格的审计日志必须能回答“谁在什么时间从哪台机器解析了什么域名、结果如何”。仅靠DNS服务器默认日志往往不够，需要显式开启查询日志并补充客户端定位信息。推荐采集的核心字段包括：请求时间戳、客户端源IP、查询的域名全称、查询类型（A、AAAA、CNAME、TXT等）、响应结果、响应IP、响应耗时以及解析是否命中黑名单。
下面以Bind9为例，给出开启详细查询日志的最小配置：
# 在 named.conf 中开启查询日志
logging {
channel query_log {
file "/var/log/named/audit.log" versions 30 size 500m;
severity info;
print-time yes;
print-category yes;
};
category queries {
query_log;
};
};
# 建议同步开启响应日志，记录返回的IP
category resolver { query_log; };日志落地之后，必须解决防篡改问题。常见的做法是把DNS日志实时转发到独立的日志服务器或者SIEM平台，转发通道使用TLS加密，日志服务器上设置仅追加权限，运维人员账号与审计账号分离。这样即使DNS服务器本身被攻破，攻击者也难以抹掉历史解析痕迹。
三、解析白名单与异常检测策略
财务系统所在的网络分区业务相对固定，非常适合推行域名白名单策略。具体做法是：财务专区内的终端只允许解析白名单内的域名（银行对账站点、税务平台、企业内部系统等），其余查询一律拒绝并记录。这样一方面压缩了DNS隧道的生存空间，另一方面任何非白名单查询本身就是高价值告警信号。
异常检测可以从几个维度设计规则：第一，单台主机短时间内查询大量不同域名且查询串长度异常，这是DNS隧道的典型特征；第二，TXT类型查询频率异常，因为隧道外传数据常借助TXT记录；第三，解析结果指向非常见地理区域或新注册域名；第四，同一域名在同一客户端短时间内的解析结果发生变化，可能意味着缓存投毒。这些规则可以在SIEM中配置，也可以用简单的脚本做基线统计。
import re
from collections import defaultdict
# 简易DNS隧道检测：统计单IP查询的域名平均长度与新域名数量
class DnsTunnelDetector:
def __init__(self, length_threshold=40, count_threshold=50):
self.length_threshold = length_threshold
self.count_threshold = count_threshold
self.seen = defaultdict(set)
def check(self, client_ip, domain):
# 域名标签过长往往是base32/base64编码数据
for label in domain.split('.'):
if len(label) > self.length_threshold:
return f"可疑隧道流量: {client_ip} 查询异常长标签 {domain}"
self.seen[client_ip].add(domain)
if len(self.seen[client_ip]) > self.count_threshold:
return f"可疑隧道流量: {client_ip} 短时间累计查询域名过多"
return None告警产生后要有明确的处置流程：先隔离终端并抓包确认，再排查是否有数据外传迹象，最后补入黑名单并复盘策略。财务场景下建议把DNS告警与终端准入系统联动，触发高危告警时自动将该终端移出财务专区，避免风险扩散。
四、内部DNS架构部署与审计留痕
架构层面，财务系统不应让终端直接使用运营商DNS。正确做法是在内网部署两台主备DNS服务器，终端的解析请求统一由内部服务器承接，上游再通过指定出口转发到可信递归服务器。这样做的好处是所有解析行为都在可控节点上产生日志，审计有了统一采集点。
对于使用Windows域的环境，可以在域控的DNS服务器上开启调试日志，同时结合组策略强制所有终端的DNS指向内部服务器，防止有人手动改成公共DNS绕过审计。此外建议定期对DNS服务器本身做配置基线核查，包括递归查询是否只对内网开放、区域传送是否限制了授权从服务器、管理端口是否暴露等。这些配置项同样是审计检查的高频抽查点，配置不当会直接导致审计项扣分。
最后要强调文档化。审计通过与否很大程度上取决于证据链是否完整：DNS架构拓扑图、日志保留策略说明、告警处置记录、定期的日志完整性校验报告，这些材料应当在日常运维中持续维护，而不是临检查前突击补齐。把DNS审计纳入财务系统安全运营的常规动作，才能真正在合规和安全两个层面都站得住脚。