行业情报
最新文章
关于基础设施运营商、政策决策、市场动向与数字权力转移的最新情报。
IETF
带宽验收签了字，等待的代价由谁接走
一条线路能把足够多的数据送出去，不等于每项业务都得到了所需的服务。TCP 测试把完成时间、重传和负载时延放在一起，真正需要交接的，是这些结果背后的取舍与责任。
IETF
Nat Sakimura 与有效签名也不能忽略的关键标头
一段 JWS 的密码学验签可以完全正确，整条消息却仍然无效。RFC 7515 用受完整性保护的 `crit` 列表把这条边界写进协议：凡被列为关键的扩展，接收方都必须理解并处理。签名字节吻合，只能证明完整性；它不能替接收方假装懂得一项改变消息含义的新规则。
互联网历史
网络升级的第一批投入，不能只靠最后一批参与者兑现
设备可以一台台更新，收益却未必一段段出现。Quick-Start 的历史提示了另一种部署成本：先行动的组织，可能要替尚未行动的组织承担等待。
互联网历史
第二个请求被删掉了，错误回执却必须晚到：RFC 1921
回执要有意义，首先得知道自己在回答哪一个请求。RFC 1921 没有给每次操作配一个全局编号，而是把同一条 Telnet 连接拆成屏幕、打印机和屏幕拷贝三本小账：每本账一次只挂一个请求。第二个请求若抢先到达，就会被删除；但对它的违规判定，还得等第一个请求的结果先说完。
IETF
弃用日期退役的是 RDAP 标签，不是它的客户端
在 IANA 登记表里把一个扩展标为弃用，只需改变一条公共记录；让分散在互联网各处的服务器与客户端真正停止使用它，却没有同一只手可以完成。REGEXT 的两份工作草案恰好把这条权力断层写进了协议设计：登记状态、服务端支持和客户端依赖是三种证据，不能由一个日期代替。
报道
AFRINIC 2025 年应收款几乎全部逾期超过 60 天，六月坏账费用为零并不等于结清
年末账龄表留下的是一批存量，半年报中的横线记录的是一段期间费用。AFRINIC 的两个数字都可能准确，却不能互相替代。把期初账龄群组如何经过收款、折让、争议、迁移、核销与减值重估抵达期末写清楚，才是既保护会员隐私、又让财务叙述可核验的办法。
互联网历史
两张网络都没错，直到它们相遇：RFC 1918 与局部唯一性的代价
两个院子里可以各有一扇“十号门”。只要围墙还在，来访者就不会走错；门牌与院子共同构成地址。企业私网也是如此。两家公司分别把同一个私有地址交给不同设备，内部路由、域名与业务都能长期正常。并购后的第一条互联线路却把围墙拆掉了。数字没有变化，答案突然有了两个。RFC 1918 真正写下的，正是这种以边界换取便利、又把未来整合成本保留下来的制度设计。
报道
RIR 草案称体系自下而上，地位变更咨询却仍可由机构选择
推荐版《RIR 治理文件》一面把互联网号码注册体系描述为开放、自下而上，另一面又在新增的第 2.7 条中明确：评估承认或取消承认某个注册机构时，RIR 与 ICANN 既未被禁止咨询各自社群，也没有义务这样做。这未必自相矛盾，却把一个关键问题留在程序之外——所谓“广泛支持”究竟从哪里来，又由谁说明没有举行咨询的理由。
IETF
Justin Richer 与无法批准请求的活跃令牌
凌晨两点，接口返回了一个看似没有歧义的结果：`active: true`。令牌没有过期，也没有被撤销，授权服务器认可它。值班人员很容易把这盏绿灯理解成“请求已经获准”。但在 Justin Richer 署名的 RFC 7662 中，这个布尔值只回答令牌此刻是否可用；真正针对业务请求的决定，仍在资源服务器手里。
IETF
多买一家 CDN，并不会自动分清谁来守住循环边界
采购可以把流量交给不同供应商，却不能把跨供应商的防护责任切成互不相干的几份。CDN-Loop 要求保留一个不可信的信号，真正考验的是谁有权改配置、谁决定拦截，以及谁能解释这次决定。
IETF
DNSSEC 恢复受多重时钟支配，任何签名方都无法独自控制
私钥已经无法工作，域名却仍能正常解析。昨天生成的签名还没有到期，于是故障被一层看似平静的服务状态遮住。DNSOP 的“DNSSEC Key Restore”草案讨论的正是这段危险的缓冲期：它给恢复争取了时间，却没有把父区、次级服务器和缓存的控制权一并交给签名方。
案例档案
一次 DNS 失败收到 51 次查询，原因仍未定位
APNIC Labs 让权威 DNS 分别回答“域名不存在”“无此记录”“服务失败”“拒绝”，或保持沉默。明确否定每次测试约收到 4 次查询；`SERVFAIL` 是 51.73 次，沉默是 83.46 次。但这份权威端账本还不能指出究竟是哪一层制造了重试。
IETF
门户网络里的“一台终端”，究竟由谁定义
一台手机可以使用多个地址，一个地址也可以先后属于不同终端。门户页面、状态接口和放行设备若没有共同维护这层对应关系，“按终端管理”就只是一句尚未说清楚的话。
IETF
Rifaat Shekh-Yusef 与不能充当交易编号的 nonce 计数
第一次通过摘要认证发送请求时，客户端写下 `nc=00000001`。这个值整齐、递增，又参与凭据校验，看起来很像一笔交易的流水号。可在 Rifaat Shekh-Yusef 主编的 RFC 7616 里，它只负责一个更窄的问题：帮助服务器识别同一 nonce 上下文中重复出现的认证请求。付款是否入账、密钥是否轮换、作业是否提交，都不在这八位十六进制数的见证范围内。
互联网历史
重编号有程序之前，先有现场日志：RFC 1916
1996 年 5 月 15 日，是一份互联网标准文档给现实世界留下的截止日期。PIER 工作组没有要求大家赞同一套既成方案，而是请正在更换网络地址的人把混乱写下来：环境是什么、计划如何、哪里失败、用了什么工具、缺了什么工具、哪一种产品必须等供应商。RFC 1916 的历史价值，恰恰来自它没有把征集证据伪装成已经掌握答案。
报道
RIPEstat 为启用 CSP 重建路由历史，新旧视图之间还需要一份语义对照记录
旧界面可以退休，旧结论却不能在无人察觉时被新默认值改写。RIPE NCC 以可维护性和浏览器安全为由重建 Routing History，方向合理；真正需要补上的，是一份让运营者分清“路由变了”与“显示方式变了”的简洁凭证。
IETF
自签名的委派更新只能证明密钥，不能证明权限
一把新密钥当然能用自己的私钥证明“我持有我自己”。这项证明在密码学上可以完全正确，在治理上却几乎没有回答最重要的问题：它凭什么取得修改子域委派的权力？DNSOP 正在讨论的方案没有跳过这道门槛，真正的挑战是让实施者也别把它抹平。
案例档案
清除请求已被接受，下游 CDN 仍然可以拒绝
一条 `201 Created` 很容易让控制台变绿。IETF 的 CDNI Triggers v2 第 20 版草案却把镜头继续推向下游：上游已经接单之后，下一家 CDN 仍可能拒绝，而拒绝会换一种记录形式返回，真正拒绝者甚至可以不具名。
IETF
采购表上的安全与速度，是否来自同一种配置
安全能力和吞吐量一旦被放进同一行，读者很容易以为两者已经同时得到验证。真正需要核对的，不只是设备型号，还有取得两项成绩时究竟启用了什么。
互联网历史
标准获准前行，许可证仍未到手：RFC 1915 的例外
一份许可表格可以被下载、审阅、签署和存档；一句“将以合理且不歧视的条件提供许可”却只能开启下一场谈判。1996 年的 RFC 1915 把这两种证据放在同一页历史里：IETF 公开了 Motorola 的承诺，也公开承认原先要求的许可文本并没有出现。程序因此重新启动，但实施者真正要承担的价格、等待与差别待遇风险仍在标准之外。