跳转到主要内容

主要领域

DNS

在 主要领域 分类下,DNS 按主要领域组织行业情报,帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境,这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景,以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。

算法拿到了编号,验证链仍未成立

IETF

算法拿到了编号,验证链仍未成立

RFC 9563 为 SM2 签名和 SM3 摘要分配了 DNSSEC 标识符,解决的是“线上如何指称”的问题。它没有替 IETF 建立共识,也没有证明密码学适用性、验证器覆盖率、策略接受度或最终解析结果。

2026年9月27日
备用权威服务器回答了,缓存的密钥却对不上:RFC 8901

IETF

备用权威服务器回答了,缓存的密钥却对不上:RFC 8901

第一家权威 DNS 提供商失效后,第二家仍能回答,并不代表验证解析器一定能接受答案。RFC 8901 揭示了 DNSSEC 冗余的真正对象:它是签名者之间的同步合同,而不是 NS 数量。

2026年9月23日
Gihan Dias:让斯里兰卡的两种文字进入根区

互联网历史

Gihan Dias:让斯里兰卡的两种文字进入根区

网络接通之后,还有谁能用自己的文字为它命名?从拨号邮件、学术网到 `.LK` 注册局,Gihan Dias 的经历揭示了斯里兰卡互联网建设中更隐蔽的一层:把僧伽罗文和泰米尔文变成可持续治理的网络标识。

2026年9月12日
从漏洞披露到可验证修复:BIND 递归与 DNSSEC 资源耗尽暴露的责任链

案例档案

从漏洞披露到可验证修复:BIND 递归与 DNSSEC 资源耗尽暴露的责任链

ISC 为 BIND 的严重漏洞提供了披露、补丁和运维指导,但公开记录并不能证明每个下游运营者都完成了部署,也不能单凭发布修复版本证明解析器在压力下恢复了韧性。真正的问责链条,始于公告,却必须延伸到暴露面清单、部署证据、服务观测和重复验证。

2026年9月10日
James Gould 与那条并不能证明政策依据的删隐标记

IETF

James Gould 与那条并不能证明政策依据的删隐标记

一份 RDAP 回应里没有出现注册人电话,读者看到的是空白,服务器看到的却可能是两段完全不同的历史:数据从未存在,或数据存在但不向这位查询者开放。James Gould 参与制定的 RFC 9537,让服务器能够把第二种情况写成结构化标记。它缩小了歧义,却没有替读者补出被隐藏的值,更没有替政策作出裁决。

2026年9月7日
内部域名的公开说明书,应该写到哪一步?

案例档案

内部域名的公开说明书,应该写到哪一步?

让客户端确认内网 DNS 的权限,不必等于把内部名称清单交给全世界。RFC 9704 把授权声明与公开核验记录分开放置,却也留下一个无法含糊处理的问题:哪些名称必须可见,哪些范围可以一次批准?

2026年9月7日
Suzanne Woolf:服务器标签不是机器身份证

IETF

Suzanne Woolf:服务器标签不是机器身份证

DNS 响应可以附带一个用来区分服务器的值。真正危险的不是这个值太少,而是运维系统把它解释得太多:把一次响应中的字节直接当成物理主机、机房位置、软件版本或永久身份。Suzanne Woolf 参与撰写的 RFC 4892 提供了更严谨的起点——先证明标签属于哪一次响应,再单独证明标签究竟指向什么。

2026年9月7日
Sara Dickinson:加密无法替解析器作出的隐私承诺

IETF

Sara Dickinson:加密无法替解析器作出的隐私承诺

把 DNS 切换为加密连接后,屏幕上的锁形图标并没有撒谎:客户端到指定解析服务之间的那段通信,确实获得了重要保护。问题在于,人们常让这把锁替更多事情作证。Sara Dickinson 参与撰写的 RFC 8932 把一条查询继续往前追,追到解析器内部、日志保存、人员权限、上游查询和答案过滤。传输安全是隐私的起点,却不是解析器承诺的全部。

2026年9月7日
Allison Mankin 与不能证明原因的名称冲突样本

ICANN

Allison Mankin 与不能证明原因的名称冲突样本

根服务器可以极其精确地记录一次形似私有名称的查询,却无法仅凭这条记录回答:查询由哪个应用产生、故障依赖归谁负责、多少用户受影响,或者未来委派会伤害什么。Allison Mankin 参与撰写的 RFC 8023,恰好为这段证据落差划出了边界。

2026年9月7日
密钥已被看见,但还不能信任

案例档案

密钥已被看见,但还不能信任

一条自签名 DNS 更新抵达父区,带来一把新钥匙,同时要求删掉旧钥匙。它能证明发送者持有新私钥,却不能证明发送者有权改变子域委派。DNSOP 最后征求意见的截止日来到 9 月 7 日,这个从“已知”到“可信”的跃迁,才是草案里真正的权力开关。

2026年9月7日
域名末尾的点消失后,信任边界换了位置

案例档案

域名末尾的点消失后,信任边界换了位置

`example.co.uk` 与 `example.co.uk.` 可以落到同一个 DNS 节点,却未必会被应用的安全组件视为同一把钥匙。DNSOP 工作组最后征求意见于 9 月 7 日截止;curl 在 2026 年披露的一项漏洞,则把“名称需要规范化”从抽象提醒变成了一个有先后顺序的控制问题:究竟是在判断权限之前去掉末尾点,还是在秘密已经越界之后才把日志写得整齐。

2026年9月6日
QNAME 最小化是一份查询序列约束,而不是隐私开关

IETF

QNAME 最小化是一份查询序列约束,而不是隐私开关

递归解析器即使显示“QNAME 最小化已启用”,不同查询向上游暴露的名称、成本和故障形态仍可能完全不同。真正可验证的对象不是一个布尔设置,而是由委派知识、缓存状态和否定响应证据共同产生的有界查询序列。

2026年9月4日
DNS 收到了提示,但父区仍须作出决定:RFC 9859 的委派边界

案例档案

DNS 收到了提示,但父区仍须作出决定:RFC 9859 的委派边界

RFC 9859 能把委派维护的检查提前;它不能把一条 DNS 通知变成父区的决定,也不能把一条响应变成 DS 已发布的证据。

2026年9月1日