行业情报
最新文章
关于基础设施运营商、政策决策、市场动向与数字权力转移的最新情报。
IETF
两字节数字也会误述载荷：RFC 9876 与 CoAP 注册表控制
CoAP 将 Content-Format 定义为一个小整数，用来标识载荷的媒体类型以及可能存在的内容编码。RFC 9876 收紧了这个整数背后的注册程序：只有媒体类型、参数、内容编码和语义都明确无歧义时，该编号才具有确定含义。
BDNOG
bdNOG公布谁监督执行委员会，却没有公布如何监督
bdNOG 官网把理事会列为最高权威，把执行委员会（EC）列为负责日常管理的机构。理事会页面称其批准年度活动并对 EC 问责。已审阅页面没有公布这条问责如何运作的程序。
IETF
无需先行协调，递归解析器也能选择加密
用户到递归解析器之间的加密，并不能自动保护下一跳。缓存未命中时，解析器仍可能以明文查询权威服务器，让路径上的被动观察者看见另一段 DNS 往来。RFC 9539 提出一项实验性折中：双方无需预先达成部署协议，也可以各自启用加密传输。这降低了协调门槛，却让解析器策略开始决定何时尝试隐私保护、何时记住成功，以及何时放弃并退回明文。
互联网历史
那扇关上却没有结束连接的窗口：TCP 持续状态
接收窗口降到零，意味着发送方必须停下，却不意味着连接已经死亡。真正棘手的是：如果“窗口重新打开”这条消息丢了，双方怎样走出等待。
全球云服务趋势
快速的 0-RTT 握手不等于交易只执行一次
TLS 1.3 与 QUIC 可以在恢复连接时省去一次往返。这证明的是时延收益，不是一次改变状态的请求只被应用接收、提交一次且不会在别处重放的凭证。
IETF
一个响应头可以使整个站点分区失效：RFC 9875 与 HTTP 缓存组
响应可以在同一个缓存、同一个 URI 源站范围内声明一个或多个不透明组标识符；随后，针对不安全请求的响应可以用这些标识符提出可能的失效操作。它解决的是局部关联，不是多个缓存、CDN 或源站之间的同步。
报道
AFRINIC 从逾 1,700 名申请者中公布五名获选者，但遴选记录并未公开
AFRINIC 的公告明确列出五人，并称遴选过程竞争激烈。然而，公告没有给出申请者精确总数、评分方法、评审人员或决定记录，因此它证明了结果，却不能让外界复核遴选过程。
IETF
DNS 目录区域把成员清单变成全服务器群的配置权
空文件通常意味着没有内容，但空的 DNS 目录区域可能是一道指令。若生成器误发了一个语法正确却没有成员的目录，原先由该目录配置的辅助服务器可能开始移除成员区域及其关联状态。真正需要治理的不是区域数据量，而是谁有权改动这张清单。
互联网历史
让不在通信路径上的攻击者更难预测的数字：TCP 初始序列号
TCP 连接以交换数字开始。历史上的关键改动不是隐藏这次交换，而是让一次可见的数字不再泄露下一条连接的起点。
全球机构趋势
有效的软件签名并不是持久的授权记录
即使发布者的职权已经变化，签名验证仍可能显示成功。密码学能证明字节与签名操作之间的关系，却不能单独证明签名者当时有权发布该版本。
ICANN
区域文件提供的是受控访问，不是重新发布命名空间的权力
上午九点，一名获准研究人员通过 ICANN 的 CZDS 下载某个通用顶级域的区域文件，校验和完全一致。这能证明一组特定字节已经交付，却不能证明每个域名由谁实际控制、为何存在，也不能自动赋予重新发布整份文件的权力。真正的治理边界就在“能够访问”与“有权使用”之间。
IETF
一条删除命令可能破坏他人的域名：RFC 9874 与 EPP 依赖控制
一次具有破坏性的 EPP 状态转换，影响范围可能超出发起请求的客户。如果某个从属主机仍与其他客户赞助的域名建立关联，删除该主机就可能改变这些域名的 DNS 依赖，造成解析失败、客户端与服务器状态不一致，或破坏关系完整性。RFC 9874 的权威来源是 RFC Editor；它提出最佳实践，并未定义新的 EPP 命令，也没有改变注册局所有权或管理权。
报道
AFRINIC 收到 1,024 个 ASN：公开记录区分库存与下游分配
IANA 于 2026 年 2 月 25 日登记了一段划给 AFRINIC 的 1,024 个 AS 号码，AFRINIC 随后在 3 月 27 日宣布已将这段号码加入库存。这些记录证明的是上游托管关系，而不是每个号码均已分配给网络运营商。
全球区域 ISP 趋势
BGP 优雅重启可能延长流量黑洞
Graceful Restart 的目标，是让 BGP 进程恢复期间的流量继续转发。它是否安全，却取决于存活会话自身无法证明的一件事：重启中的路由器是否真的保留了相关转发状态。如果邻居保留陈旧路由的时间超过转发状态的存续时间，一次看似平稳的控制面恢复反而会延长数据面故障。
IETF
第二个地址成为主地址：RFC 9873 如何改变 EPP 联系人数据
一次 EPP 联系人更新现在可以形成更明确的状态转换：联系人对象可保存一个额外电子邮件地址， 可选的 `primary` 属性说明哪个地址应被视为主要地址。协议记录的是这种关系，并不验证邮箱归属、保证邮件送达，也不保证所有下游流程都会采用这一选择。
IETF
默认拒绝让缺失的 EBGP 策略从隐性授权变成显性故障
一条外部 BGP 会话可以已经建立，但接收或通告路由的权限仍未定义。RFC 8212 改变了这个边界的默认值：没有导入策略就不接收路由，没有导出策略就不通告路由。领导者要问的不是会话是否在线，而是谁授权了两个方向，以及这种授权在升级后是否仍然有效。
案例档案
六十个域名列在被告席上，但诉因仍由法律定义：Harrods 诉六十个互联网域名案
案名本身就不寻常：被告栏里不是某位注册人，而是六十个域名。这种写法很容易让案件看起来像一场法院直接处置网络标识的行动。第四巡回上诉法院给出的答案却更克制。域名可以成为对物诉讼的对象，但这种程序路径既不会自动证明侵权，也不会替当事人补足商标权、恶意或法定管辖前提。
互联网历史
让公钥变得可信的链条：PEM 证书管理
公钥只是一段密码学材料，并不会自行说明持有者是谁。RFC 1422 为隐私增强邮件设计了证书、认证机构、验证路径与吊销信息，使收件人能够检查“姓名与密钥之间的绑定”由谁作出、又凭什么值得信任。
IETF
增强型 uRPF 让运营者接纳可行源路径，而不是信任所有路由
多宿主客户发出的合法数据包，可能从接收路由器不会用于返程的链路抵达。严格检查可能误丢它，宽松检查却可能放行任何已有路由的源地址。RFC 8704 给出更窄的中间边界：为每个接口建立可行源路径集合，并把这个集合的授权依据与运行成本说清楚。
IETF
前缀先于查询到达：RFC 9872 如何改变 NAT64 发现
仅有 IPv6 接入的终端若要访问 IPv4 服务，必须知道网络用于合成地址的 IPv6 前缀。RFC 9872 把这项信息放回接入网络：先从路由器通告学习 PREF64，无法取得时再使用 DNS 发现。