TTL 不是解析时间
Windows 客户端的 DNS 缓存里，每条记录都带一个剩余 TTL，它随缓存存活而递减，只能说明这条记录还没过期，不能反推域名是在什么时刻被解析的。缓存的写入时刻不会记录在缓存条目里，靠读 TTL 去推断解析时间，是最常见的 DNS 取证误判之一。
什么才是可靠来源
要确定解析发生的时刻，应当使用客户端进程级的 DNS 事件（Sysmon 事件 22，含 QueryName 与 Image 字段）、DNS 服务器的查询日志，或者出口防火墙上的 DNS 流量记录。其中只有客户端侧进程级事件才能把域名解析绑定到具体进程，服务器日志只能给出客户端地址与域名。
基本信息
| 适用平台 | Windows 客户端（ipconfig）、Windows Server DNS 服务 |
|---|---|
| 查看缓存 | ipconfig /displaydns |
| TTL 语义 | 剩余存活时间，随查询递减，不等于写入时间 |
| 可靠时间源 | Sysmon 事件 22、DNS 服务器查询日志、防火墙 DNS 记录 |
| 估算前提 | 必须已知该记录的初始 TTL，才能倒推存活时长 |
典型使用场景
- 样本释放出域名但不知何时解析：改从 Sysmon 22 事件取时间，而不是读缓存
- 排查定向钓鱼域名：用 DNS 服务器日志确认客户端查询时刻，再与邮件时间对齐
- 验证缓存中的可疑记录是否仍在有效期内：判断主机是否可能继续外联
- 为无法部署 Sysmon 的环境找替代：用 DNS 服务器日志加防火墙记录交叉
- 报告方法章节说明局限：明确 TTL 只作旁证，不作为时间结论依据
查看缓存与事件
查看缓存与事件
# 只用于确认缓存内容，不要用 TTL 推时间
ipconfig /displaydns
# 进程级 DNS 事件：含查询时间与发起进程
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=22} -MaxEvents 20 |
Select-Object TimeCreated, Id | Format-Table -AutoSize
# DNS 服务器侧查询日志（需先启用调试日志或分析日志）
Get-WinEvent -LogName 'DNS Server' -MaxEvents 10 | Select-Object TimeCreated, Messagedisplaydns 字段读法
| 字段 | 含义 | 使用注意 |
|---|---|---|
| Record Name | 被查询的域名 | 常带尾部点，比对时先归一化 |
| Type | A、AAAA、CNAME、PTR 等记录类型 | 不同类型初始 TTL 不同 |
| Time To Live | 剩余秒数 | 随缓存存活递减，不能当解析时间 |
| Data Length | 记录数据长度 | 用于校验记录完整性 |
| Section | Answer 或 Additional | Additional 多为附带解析结果 |
清空 DNS 缓存（ipconfig /flushdns）会把全部记录一并移除，缓存快照是不可再生的状态，可疑主机处置前先导出留存。
若只有缓存快照且已知初始 TTL，可以用「初始 TTL 减剩余 TTL」算出缓存已在内存中存活的时长，得出一个时间区间；结论里必须写明初始 TTL 的来源与假设。