主要领域
DNS
在 主要领域 分类下，DNS 按主要领域组织行业情报，帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境，这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景，以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。
领导者
Dean Pemberton 想把“脏”IPv4 地址变成 DNS 入口：APNIC 周四点头，周五摇头
`1.2.3.0/24` 因垃圾流量长期被 APNIC 隔离。Pemberton 提议把它交给局部范围的 DNS anycast 解析器使用。政策小组赞成，次日会员大会却未达共识。让地址显得有用的流量麻烦，也正是它的运行风险。
学者
Giovane Moura 呼吁统一 DNS 统计，.nl 的 IPv6 旧账无法重算
SIDN 把 .nl 的 DNS 统计放进 RSSAC-002 格式，方便研究者对照。它自己的仓库也写明：一天没有数据，早期 IPv6 来源计数已无法重算。
IETF
Joe Abley 的 DNSSEC 测试：中位数只多 1 毫秒，p99 多 1.405 秒
Cloudflare 的早期后量子 DNSSEC 测试，中位数几乎没动；最慢的 1% 却多等了 1,405 毫秒。验证型解析器的图表还把总体结果标成 6.0% 的净故障。真正的争执藏在签名规则里：新的后量子签名坏了，旧的经典签名还能不能兜底？
ICANN
DNS 滥用月份更多，活动规模却小 38%：Carlos Gañán 把两本账拆开
在 1,106 个 gTLD 中，Category 1 每月出现滥用的概率高 3.1 个百分点；滥用出现后，预期活动规模低 38%。合并模型估计，每个 gTLD 月份的恶意注册域名总量低 37%。
学者
Ginevra Fabrizio 省下 11 字节，NXDOMAIN 响应仍越过 MTU
在 RIPE 93 上，特温特大学研究者用一天的 `.nl` 查询重放，对比了两种 Falcon-512 签名格式。未填充签名的中位数为 655 字节，比固定长度的 666 字节少 11 字节；每条受测 NXDOMAIN 响应仍超过研究采用的两个包长阈值。
IETF
算法 18 已有编号，Joe Abley 却碰上了 EPP 门槛
IANA 已将 ML-DSA-44 列为 DNSSEC 算法 18。RIPE 93 上，Joe Abley 讲到下一道关：注册局仍可能拒收运营方通过 EPP 提交的 DS 数据。他在 10 月发布的个人草案，主张让这些接收规则跟随 IANA 注册表。
学者
加密后的 DNS 仍会露出信号：Martine Sophie Lenders 找到了那个破绽
她研究的不是如何读出查询，而是加密之后，包的形状还能否暴露 DNS 流量；在 296 种受限 IoT 部署场景中，分块传输与头部压缩把这条信号压低，却没能抹掉它。
全球机构
五个已修复版本与一个含糊的词：读懂 CVE-2025-40778
BIND 9 的 DNS 解析器中有一处缓存投毒缺陷，已经被修复。留存下来的这份报告精确列明由哪些构建完成修复，却把「哪些构建曾受影响」留给了一个词——「various」。对要签字放行升级的人来说，值得追问的正是这一不对称：这份记录能证明什么，又在何处悄悄失效。
案例档案
Dyn 仍在应答。没有任何文本给解析层设定义务。
一家共享域名服务商在 2016 年 10 月吸收了僵尸网络流量，公共记录从此把它留在“一次宕机”的叙事里。随后的文件比故事更奇怪：先是针对发起流量的设备的一份联邦警示，然后是一部关于联邦政府自有设备的法律。两者都没有触及那一层实际回答查询的系统。
领导者
雷·贝利斯：一个人写下的句子，和一份不需要他同意就能存续的登记表
同一个工程师，两份性质完全不同的文件。一份由单人署名，用最硬的动词禁止别人破坏不认识的东西；另一份有六位作者，用最硬的动词让两台机器共同维持一个谁也无法单方面宣布成立的状态。两者的对照，标出了标准文本作者的权力究竟止于何处。
ICANN
.org 收购受阻：一个没有公开标准的同意权
2019 年 11 月，互联网协会（Internet Society）同意把 .org 顶级域名的注册管理机构 Public Interest Registry 出售给私募股权公司 Ethos Capital。2020 年 4 月 30 日，ICANN 董事会拒不同意该 .org 注册管理机构协议的控制权变更，交易随之终止。结果有据可查，所依据的标准却没有。
IETF
算法拿到了编号，验证链仍未成立
RFC 9563 为 SM2 签名和 SM3 摘要分配了 DNSSEC 标识符，解决的是“线上如何指称”的问题。它没有替 IETF 建立共识，也没有证明密码学适用性、验证器覆盖率、策略接受度或最终解析结果。
IETF
备用权威服务器回答了，缓存的密钥却对不上：RFC 8901
第一家权威 DNS 提供商失效后，第二家仍能回答，并不代表验证解析器一定能接受答案。RFC 8901 揭示了 DNSSEC 冗余的真正对象：它是签名者之间的同步合同，而不是 NS 数量。
互联网历史
Gihan Dias：让斯里兰卡的两种文字进入根区
网络接通之后，还有谁能用自己的文字为它命名？从拨号邮件、学术网到 `.LK` 注册局，Gihan Dias 的经历揭示了斯里兰卡互联网建设中更隐蔽的一层：把僧伽罗文和泰米尔文变成可持续治理的网络标识。
案例档案
从漏洞披露到可验证修复：BIND 递归与 DNSSEC 资源耗尽暴露的责任链
ISC 为 BIND 的严重漏洞提供了披露、补丁和运维指导，但公开记录并不能证明每个下游运营者都完成了部署，也不能单凭发布修复版本证明解析器在压力下恢复了韧性。真正的问责链条，始于公告，却必须延伸到暴露面清单、部署证据、服务观测和重复验证。
IETF
James Gould 与那条并不能证明政策依据的删隐标记
一份 RDAP 回应里没有出现注册人电话，读者看到的是空白，服务器看到的却可能是两段完全不同的历史：数据从未存在，或数据存在但不向这位查询者开放。James Gould 参与制定的 RFC 9537，让服务器能够把第二种情况写成结构化标记。它缩小了歧义，却没有替读者补出被隐藏的值，更没有替政策作出裁决。
案例档案
内部域名的公开说明书，应该写到哪一步？
让客户端确认内网 DNS 的权限，不必等于把内部名称清单交给全世界。RFC 9704 把授权声明与公开核验记录分开放置，却也留下一个无法含糊处理的问题：哪些名称必须可见，哪些范围可以一次批准？
IETF
Suzanne Woolf：服务器标签不是机器身份证
DNS 响应可以附带一个用来区分服务器的值。真正危险的不是这个值太少，而是运维系统把它解释得太多：把一次响应中的字节直接当成物理主机、机房位置、软件版本或永久身份。Suzanne Woolf 参与撰写的 RFC 4892 提供了更严谨的起点——先证明标签属于哪一次响应，再单独证明标签究竟指向什么。
IETF
Sara Dickinson：加密无法替解析器作出的隐私承诺
把 DNS 切换为加密连接后，屏幕上的锁形图标并没有撒谎：客户端到指定解析服务之间的那段通信，确实获得了重要保护。问题在于，人们常让这把锁替更多事情作证。Sara Dickinson 参与撰写的 RFC 8932 把一条查询继续往前追，追到解析器内部、日志保存、人员权限、上游查询和答案过滤。传输安全是隐私的起点，却不是解析器承诺的全部。
ICANN
Allison Mankin 与不能证明原因的名称冲突样本
根服务器可以极其精确地记录一次形似私有名称的查询，却无法仅凭这条记录回答：查询由哪个应用产生、故障依赖归谁负责、多少用户受影响，或者未来委派会伤害什么。Allison Mankin 参与撰写的 RFC 8023，恰好为这段证据落差划出了边界。