主题
网络资源证据
在主题维度下，网络资源证据主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
互联网历史
必须由答案取代的提示：DNS 根引导如何建立当前起点
递归解析器启动时掌握着一种尴尬的知识：它知道若干可以抵达 DNS 根的地址，却还没有任何当前根数据。根引导用一次很小的交换，把随软件分发的提示换成权威、可过期的答案。
互联网历史
报错没有说谎，却漏掉了转发依据：MPLS 标签栈怎样进入 ICMP
一份错误报告可以准确引用原来的 IP 数据报，却没有留下路由器实际用来转发它的那组标签。2007 年的一个 ICMP 扩展补上了这段记录。它增加的不是一张完整网络地图，而是一份有时间、有位置、也有披露边界的现场证据。
报道
ARIN 的 RDAP Bottom 搜索回答的是覆盖问题，而不是叶节点清单
对一个 `/21` 发起查询，结果里同时出现直接分配的 `/22` 和管理状态的 `/8`。只有把 `rdap-bottom` 误读成“所有下级对象”时，这个结果才显得颠倒；它真正计算的是登记层面的完整覆盖。
报道
LACNIC候补名单末位至少等12年，最多获得1,024个IPv4地址
进入 LACNIC 的 IPv4 候补名单，并不意味着一段地址已经被预留。申请人得到的是一个绑定于机构身份的程序位置；在回收地址真正释放之前，供应量、实际顺序、最终批准和地址质量都没有落定。
互联网历史
两种零，一条回路：PPP 怎样认出自己发出的数
零有时表示“这项能力没有启用”，有时却是必须拒绝的提议。PPP 的 Magic-Number 没有神奇到能凭一个数字识别远端；它的价值在于，把收到的数字放回报文类型、协商方向和本地记录之中，判断线路是不是把自己的话送了回来。
报道
ARIN 的 NET 路由列表不包含子网
空列表看起来很有结论性，前提是忽略查询边界。ARIN 路由注册 API 的普通 NET 列表只查看直接登记；下游再分配属于另一种请求。
互联网历史
SMTP 不挂断也能忘掉的邮件：RSET 如何划定事务边界
服务器已经记住一个发件人和一位收件人，客户端却在第二位收件人被拒后决定整封邮件作废。`RSET` 让双方能够确认“忘掉这次未完成投递”，同时保留仍然可用的 SMTP 会话。
互联网历史
文件名栏里没有文件名：DHCP 怎样借用旧字段
报文里一块名叫 file 的空间，可以不再装启动文件名。但接收端不能靠猜：它必须先在另一处读到明确声明，再按共同顺序解析和重组。DHCP 对旧字段的借用，展示了协议扩容真正困难的部分——不是找到空位，而是让所有参与者知道这些字节此刻是什么意思。
互联网历史
第二次查询，可能已经换了服务器：DNS NSID 要认的是哪一份回答
一个 DNS 地址可以由许多实例共同提供服务。遇到异常后再问“你是谁”，得到的身份未必属于刚才作答的那一台。2007 年的 NSID 把标识放进原本需要诊断的回答，却刻意没有把它变成全球统一的服务器身份证。
互联网历史
拥塞抹掉的那一位：ECN Nonce 怎样核对一份“没事”的回报
一个路由器只需把两种标记改成同一种标记，就会毁掉接收端不知道的随机信息。2003 年的 ECN Nonce 想利用这点损失，检验拥塞是否被隐瞒；十五年后，实验的退场又提出另一道问题：正确的机制，是否值得一直占用公共码点？
互联网历史
先报服务名，再开始交谈：TCPMUX 把选择权留在主机上
1988 年的一份短规范提出，让新服务共用 TCP 端口 1。它节省的不是连接，而是每项服务都要取得专用公共编号的步骤；省下这一步以后，谁来决定名字指向哪个程序，反而更清楚了。
互联网历史
一位无法维持服务的比特：DNS WKS 为何没能成为实时目录
一封邮件还没有发出第一个 TCP 报文，投递程序就可能因为 DNS 里的第 25 位是零，先把一台邮件服务器从候选名单中划掉。WKS 的教训，藏在这个过早的判断里。
案例档案
编号还是 256，含义却已经换了：IPFIX 观察域能证明什么
导出器重新连上后，采集器又看见 Template ID 256。它沿用上一条传输会话缓存的字段定义，把新字节切成一组看似合理的计数。仪表盘没有报错，解析器也很满意，错的是每个数字旁边的名称。256 从未承诺自己是一份全球通用的格式。
互联网历史
只能说出一台服务器所知姓名的答案：DNS 为何淘汰 IQUERY
DNS 曾经允许一种倒置的提问：问题区空着，答案区却先放进一条资源记录，服务器再去找“哪些名字拥有这个值”。这种对称感很诱人——既然普通查询能从名字走到记录，为何不能沿原路返回？难点不在报文能否倒过来写，而在 DNS 的权威是按名字树分派的。任意记录值并没有相应的委派路径。IQUERY 能诚实地搜索一台服务器看得见的资料，却无法证明该问的正是它，更无法证明它没有漏掉别处的名字。
案例档案
TXT 记录完全正确，供应商仍不等于域名所有者：ACME DNS-01 与委托验证的权限边界
供应商的员工账号、CI 密钥和证书库权限都已撤销，`_acme-challenge` 却仍委托到它管理的验证区。供应商用尚存的 ACME 账户申请通配符证书，正确的 TXT 摘要随即出现，验证全部通过。协议没有出错；漏项发生在只画到应用层的离场清单里。
案例档案
边界不是过滤器：BGP 最大前缀数如何把容量预算变成断会话权限
多一条路由，为什么可能导致此前已经正常承载流量的整组路由一起撤走？答案不在那条新路由是否“有问题”，而在最大前缀数策略把计数结果绑定了什么动作。只有把计数口径、保护对象、合理余量、执行后果和转发证据写清楚，这个看似简单的上限才是一项可治理的网络控制。
互联网历史
那封无法说出哪个包已到达的回执：Karn 算法如何教 TCP 拒绝一次测量
同一段 TCP 序列空间先后发出两次：第一次是原始发送，第二次发生在计时器到期之后。随后只有一个 ACK 把确认边界向前推进。它足以证明接收端已经越过那些字节，却没有说明究竟是哪一次发送促成了确认。Karn 算法把这个缺失的因果标签变成一条运行纪律：宁可暂时没有新的往返时间，也不能让无法归因的样本改写 TCP 的时钟。
案例档案
DNS 回答安全，不等于主机选择正确：SSHFP 指纹的权限边界
运维人员输入 `ssh db`。网络下发的搜索后缀把短名补成了另一个完整域名；该名称的 SSHFP 通过 DNSSEC Secure 验证，服务器给出的主机密钥也与指纹完全一致。所有密码学证明都成立——只是成立于客户端选中的主机，而非操作者心中那台数据库。
案例档案
签名通过了，From 地址却不是签名者：DKIM 域签名的权力边界
邮件把 `bank.example` 显示为 From 域，DKIM 结果为 pass；真正完成签名的却是攻击者控制的 `receipt-alert.example`。密码学没有出错，系统只是把一个域的证明送给了另一个域。
案例档案
摘要完全吻合，发送者仍然未知：HTTP `Content-Digest` 与校验和的权力边界
那份策略文件没有在传输途中损坏。它从一开始就是恶意内容，而且附带了计算完全正确的 `Content-Digest`。服务显示“已验证”，随即执行文件。攻击者没有破解哈希算法；他只是同时选择了正文和摘要。