Summary

  • IOTOPS 物联网 DNS 指南草案第 06 版更新于 2026 年 11 月 2 日，仍是工作组修订中的 Internet-Draft。第 4.3 节指出两种行为：设备无视 TTL 反复查询，以及不管运行变化都按固定节奏查询同一域名。
  • 厂商须为管理区记录选择合适的 TTL。过短会增加查询，过长会拖慢管理服务器地址变更；设备缓存也须按 TTL 处理记录，除非有明确配置的上下限。
  • 关键域名若确需定期复查，间隔宜有非确定性。解析失败后应退避；RFC 9520限制向同一服务器的重试，并要求至少缓存一秒失败结果。

设想一批摄像头不管 DNS 答案给多长 TTL，都每六十秒查询一次管理域名。一次固件更新把节拍改成九十秒。观察网络的人不必看到机身标签，就能按节奏把两批设备分开。这个例子用于检验草案指出的风险机制，并非某款摄像头的实测结果，也不提供识别成功率。

第一只钟在权威 DNS 服务器手里。RFC 1035 的 TTL 规定答案可缓存多久。设备若为了重要管理域名另设复查计划，那是第二只钟。解析失败时，重试与退避又开启第三只钟。厂商若用一条写死的定时任务盖过全部三者，查询量和可辨识性都会跟着固件决定。

心跳太整齐，也会变成产品铭牌

草案第 4.3 节描述的固定查询，不随 TTL 或运行状态变化。文本明确指出，旁观者可以从查询时间剖面推测设备型号或固件版本。这是风险，不是草案给出的识别实验成绩。重复查询还消耗受限设备的电力，给解析器增加工作。厂商办公室里整洁的一行定时配置，到了客户网络上就成了设备名单的节拍器。

权威区的 TTL 也不能随手填。太低，设备为了同一个答案重复付费；太高，管理服务器地址搬迁后旧答案留得太久，软件更新可能走错地方。草案要求厂商依据记录用途设定时长，并让有资源的设备缓存应答。缓存存在时，设备必须按 TTL 过期或处理，除非明确配置了最小或最大缓存期限。支持这种上下限的设备应让授权管理者调整，而不是把数值烧死在固件里。一个被设备无视的 TTL，无法承担厂商声称交给它的控制职责。

有些关键域名确实需要周期性确认。草案允许这种业务理由，却要求重复查询的间隔不要机械固定。打散时间也不能让设备无限期抱着旧地址。实测办法很直接：更改管理域名的 A 记录，留下旧 TTL、设备缓存失效时间、下一次查询时间和第一次成功连接新地址的记录。后台写着“已启用随机抖动”，不等于网络线上真的这样运行。

解析器故障则考验另一种节律。若整支设备队伍同时重新提问，厂商自己的恢复机制会制造查询尖峰。草案要求退避，并引用 RFC 9520：同一问题、同一服务器地址和同一传输方式，重试至多两次就要将服务器视为对该问题无响应；解析失败至少缓存一秒。RFC 8767 还提供在特定故障时使用先前有效旧答案的办法。旧答案、失败缓存和重试中，是三种不同的运行状态，不能都用“DNS 正常”遮住。

厂商的定时器，最终占用运营者的网络

草案另有一条硬要求：设备的 DNS 解析器配置须能通过适用的网络协议或授权设备管理来调整，不得偷偷退回固件写死的公共解析器。建议的顺序是人工设置、授权管理软件，再到路由通告或 DHCP 给出的网络配置。运营者要迁移解析服务或处理查询洪峰时，这项控制权有用。秘密公共回退会在故障时把设备查询带出本地策略，恰好让真正承担网络成本的人失去抓手。

官方文件没有给出型号识别率、某支设备队伍的耗电差额或实际攻击事件。要改变判断，应对不同固件做受控抓包，同时更改 TTL、管理服务器地址并让解析器故障。眼下规范给出的动作已足够明确：发布合适的 TTL，让设备缓存真正服从它；必要复查打散节拍；失败后慢下来。设备应跟随 DNS 事实工作，而不是用钟声自报家门。

IOTOPS 草案 · RFC 1035 · RFC 9520 · RFC 8767