DNS记录中的“幽灵”NIMLOC：其实是macOS遗留的NetBIOS
SANS ISC 安全分析报告：DNS记录类型32（NIMLOC）在日志中频繁出现，经证实实为macOS系统遗留的NetBIOS广播。本文详解IANA记录类型演变、Zeek命名误导及实际安全影响，帮助安全分析师正确识别并消除误判。
🔍 Low 其他
安全分析师Johannes Ullrich在DNS日志中发现大量NIMLOC（类型32）查询，经分析确认这些查询并非针对早已废弃的Nimrod路由架构，而是macOS系统基于旧版RFC 1002发出的NetBIOS名称服务广播。Zeek将类型32标识为NIMLOC，但实际对应的是NetBIOS的NB记录，属于历史遗留行为，不会带来直接安全威胁。
来源：SANS ISC | 2026-07-07 | 原文链接
🔍 关键发现
- DNS类型32被IANA当前分配为NIMLOC（Nimrod Locator），但早期实际用于NetBIOS（NB）名称服务（RFC 1002）。
- macOS系统仍在发送类型32的DNS查询，这是对旧版NetBIOS协议的向后兼容行为，并非真正的Nimrod协议流量。
- Zeek日志工具将类型32显示为NIMLOC，容易误导分析人员认为存在异常协议，实则是正常的广播行为。
⚔️ 攻击链分析
无攻击链。该现象仅为网络设备历史兼容行为，不涉及攻击步骤。
🚩 失陷指标 (IOC)
DNS查询记录中Type值为32（NIMLOC/NB）的流量目标端口UDP 137的NetBIOS名称服务广播
🛡️ 缓解建议
- ✅ 建议在安全监控平台中正确识别DNS类型32的IOC，避免误判为异常协议。
- ✅ 若无需NetBIOS支持，可在macOS系统中禁用相关服务（如关闭文件共享的NetBIOS over TCP/IP）。
- ✅ 使用Zeek等日志工具时注意RR类型映射，建议结合实际RFC参考（如RFC 1002）而非仅凭IANA当前命名。
涉及漏洞：[]
⚠️ 本文仅供安全研究与学习，IOC 信息请勿用于非法目的。
🤖 常见问题解答（FAQ）
❓ NIMLOC记录是否代表存在攻击？
通常不是。NIMLOC（类型32）在现网中绝大多数是NetBIOS名称查询，属于历史兼容行为，macOS系统常见。需结合上下文判断，单独出现无安全风险。
❓ 如何区分真实的NIMLOC与NetBIOS？
查看载荷内容：NetBIOS名称请求包含特定的名字结构（如<00>、<20>等后缀），且目的端口为UDP 137。而真正的Nimrod协议从未大规模部署，几乎不存在。
❓ 是否需要封禁DNS类型32流量？
不建议直接封禁，因可能影响macOS局域网文件共享等正常功能。若需严格控制，可在防火墙规则中仅允许已知合法设备，或升级操作系统至最新版（Apple已逐渐减少依赖）。