RCS崛起唤醒沉睡的NAPTR：你的DNS流量中暗藏SIP信令通道
SANS ISC安全分析师详解RCS协议中的NAPTR DNS记录：从谷歌Verizon RCS节点抓包分析看SIP服务器发现机制、潜在攻击面（正则表达式滥用、SIP降级）及检测缓解方法。适合网络安全运维和DNS安全研究人员阅读。
🔍 Low 其他
随着iOS和Android对RCS（富通信服务）的广泛支持，NAPTR DNS记录在网络上大量涌现。安全分析师通过抓包发现，RCS利用NAPTR+SRV记录链定位SIP服务器（如Verizon的Google RCS节点），该机制虽非漏洞，但正则表达式解析功能可能被攻击者滥用或用于信息侦察。
来源：SANS ISC | 2026-07-06 | 原文链接
🔍 关键发现
- NAPTR记录（RFC 2915）已从理论走向实际应用，目前主要用于RCS服务的SIP服务器发现
- 典型RCS NAPTR记录返回'SIPS+D2T'服务标识，引导客户端查询SRV记录，最终获取A/AAAA记录和端口
- 谷歌公开域 'fp-us-verizon.rcs.telephony.goog' 成为RCS信令关键基础设施，可被用于流量指纹识别和供应链攻击面分析
⚔️ 攻击链分析
1. 攻击者伪造或篡改NAPTR记录中的正则表达式字段，将合法RCS终端重定向至恶意SIP服务器 2. 恶意SIP服务器伪装成运营商RCS网关，拦截或劫持加密通信前的SIP握手 3. 通过降级攻击迫使客户端使用未加密SIP或明文RCS消息，窃取用户对话内容
🚩 失陷指标 (IOC)
fp-us-verizon.rcs.telephony.goog（RCS SIP服务器域名）SIPS+D2T（NAPTR服务标识，表示安全SIP直连TCP）NAPTR查询类型（type 35）突增的DNS流量
🛡️ 缓解建议
- ✅ 在企业网络中部署DNS日志审计，监控异常NAPTR查询（尤其是外部域名的正则表达式非空记录）
- ✅ 对内部DNS服务器启用DNS-over-TLS/HTTPS，防止中间人篡改NAPTR响应
- ✅ RCS服务提供商应在NAPTR记录中强制使用空正则表达式（当前主流实践），并启用DNSSEC签注防止缓存投毒
涉及漏洞：[]
⚠️ 本文仅供安全研究与学习，IOC 信息请勿用于非法目的。
🤖 常见问题解答（FAQ）
❓ NAPTR记录为什么突然增多？
iOS 18和Android 14默认启用RCS，客户端通过DNS NAPTR查询Google/运营商RCS服务器的SIP位置，导致全网流量上升。
❓ 如何检测RCS相关的NAPTR攻击？
关注NAPTR响应中'Flags'非's'或'u'的记录，以及'Regex'字段非空的记录，这可能是恶意重定向的信号。
❓ 普通用户需要担心吗？
当前主流服务（如Google Messages）的NAPTR正则表达式为空，风险较低。但攻击者可能利用SIP协议降级攻击，建议保持RCS端到端加密始终开启。