网站域名基础㉕域名与物联网 设备如何被命名

网站域名㉕域名基础 域名与物联网 设备如何被命名

前面讲的都是“人访问服务”。物联网把问题反转了：几百万台设备，绝大多数没有键盘、没有屏幕，它们之间怎么互相找到对方？靠 IP 显然不现实——IP 会变，数量又大，人根本记不住。于是命名这件事必须交给域名体系来做。

设备命名到底要解决什么

把自己代入平台方想一遍：我要知道某一台设备是谁（唯一标识），要能主动找到它（可寻址），要能按批次、按型号、按区域成组管理（可分组），最好还能一眼看出它属于谁（可读）。这四件事，域名天然都能对应上：层级结构就是分组，全局唯一就是标识，解析就是寻址，可读性本来就是域名存在的理由。

做法一：把设备编号做进子域

最直白的方案是给每台设备一个子域，形如 dev-0001.iot.example.com。编号即身份，天然唯一；批号写进前缀就能成组下发策略；解析记录由平台按需生成和回收。设备上线时向平台注册，平台写一条解析；设备下线，记录撤掉。整个过程和网页域名的增删没有本质区别。

难点在规模。百万级子域意味着百万条记录，解析查询量会成倍上去，普通的权威服务根本扛不住。所以这条路通常要和短 TTL、多级缓存、任播解析一起用，才能撑住。

做法二：消息协议里的“主题命名”

很多物联网设备并不直接互相寻址，而是通过消息中间的转发层通信。这时候用到的不是域名，而是主题（topic）——但它和域名的组织思路几乎一模一样：用斜杠分层，可以按前缀批量订阅，可以用通配符一次覆盖一批设备。

比如把主题设计成 设备类型/区域/设备编号/属性，平台就能一条订阅规则收到华东所有温湿度设备的数据。设备身份、分组、路由，三件事在这套命名里一次解决。域名教给我们的层级化思维，换了个载体继续用。

做法三：局域网里的本地发现

智能家居是个例外——设备常常就在同一个局域网里，根本不需要公网域名。这时候用的是前面讲过的 mDNS 一类的本地发现机制：设备上线后主动广播“我叫这个名、我能做什么”，家里的中枢收到就能直接按名访问。

好处是断网也能用，响应快，不依赖任何云服务；代价是只能覆盖一个广播域，跨网段就不灵了。所以家用场景多用本地发现，商用场景仍然要走云端命名。

命名即身份：一机一证

物联网最值得强调的一点，是命名和安全天然可以合一。设备出厂时签发唯一证书，证书里的域名（CN 或 SAN 字段）就是这台设备的身份，平台侧要求双向验证：设备要证明自己是这个域名，平台也要证明自己可信。

这样一来，“假设备接进来冒充真设备”这条路就被堵住了。密码可以猜、可以撞库，一机一证的私钥却没法批量复制——这也是为什么正规物联网方案都往证书认证上走。

规模上来之后的三个坑

第一是 TTL。设备位置会变，解析得跟得上变化，TTL 只能设短；TTL 一短，查询量又顶上来。第二是解析服务本身成了全局单点——几百万设备同时重启，解析请求会瞬间打满，必须用任播和分级缓存兜住。第三是回收。设备报废、编号复用、记录残留，没人管就会积累成一堆指向空处的脏解析，后期排查极其痛苦。

给物命名，本质上是给物发身份证。下一篇看点更激进的路子——把域名整个搬到区块链上，连注册局都不要了。

本文收录于徐果萍文集《论持久站 网站域名》，徐果萍博客原创首发。