历史

从阿帕网（ARPANET）时代一直到互联网的早期，网络节点比较少，都是通过本地 hosts 文件来实现主机名到 IP 地址的映射。

根据维基百科的信息，斯坦福研究所（SRI-NIC，Stanford Research Institute Network Information Center）负责维护一个公共 HOSTS.TXT 文件（RFC 606、RFC 608），各个网络节点定期通过 FTP 下载最新版本进行同步。

PS：这个时候如果有主机名重复了谁来管？打电话过去让他们改名？

这套机制一直运行了十几年。随着互联网规模扩大，公共 HOSTS.TXT 文件变得越来越大，变化也越来越频繁。每当有新的主机加入网络、IP 地址发生变化，都需要重新同步整个文件。

这种模式存在几个明显问题：

• 中央管理机构压力越来越大；
• 全网频繁同步效率较低；
• 主机数量增长后难以维护；
• 名称冲突和管理问题越来越复杂。

后来人们开始设计域名和域名相关的公共设施。RFC 819《The Domain Naming Convention for Internet User Applications》和 RFC 881《The Domain Names Plan and Schedule》提出了域名系统的早期设计思路。

最终在 1983 年形成了下面两个 RFC 文档：

• RFC 882, DOMAIN NAMES - CONCEPTS and FACILITIES
• RFC 883, DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION

几年后（1987），正式的 DNS 标准 RFC 1034 和 RFC 1035 推出。我们现在常见的 A / MX / NS / CNAME / PTR / SOA 等记录类型都是在这个标准中定义的。

• RFC 1034, Domain Names Concepts and Facilities
• RFC 1035, Domain Names Implementation and Specification

这套标准一直运行到现在。虽然几十年来不断增加新的记录类型、支持国际化域名（IDN）、引入 DNSSEC、安全加密传输等扩展能力，但其核心设计思想基本没有改变：

• 分层命名；
• 分布式管理；
• 缓存加速；
• 递归解析。

DNS 可以说是互联网历史上寿命最长、最成功的基础设施之一。并且，在可以预见的未来，DNS 仍然会是互联网最重要的基础设施之一。

DNS over TCP

最初 DNS 主要运行于 UDP 53 端口。RFC 1035 同时规定了 TCP 支持，最早 TCP 主要用于：

• 区域传送（AXFR）；
• 超大响应数据返回。

今天绝大多数 DNS 服务仍同时支持 UDP 和 TCP。

DNS 的管理权问题

互联网本是美国国防部高级研究计划局（DARPA）的产物，早期域名分配几乎由南加州大学教授乔恩·波斯特尔一人代管。1998年，克林顿政府为避免让联合国下属的国际电信联盟（ITU）——一个由各国政府和官营电信主导的机构——接管互联网，刻意设计了一条"私有化"路线：成立非营利组织 ICANN，负责全球域名系统（DNS）和顶级域名分配，与美国商务部签合同但通过"私人身份"运作，以此保持互联网开放、不受单一政府直接操控。然而 ICANN 总部在加州、受美国法律管辖，全球13台根服务器多数也在美国手里，等于事实上的互联网域名最高仲裁者仍是美国。这让包括中国、俄罗斯在内的大量国家长期不满，伊拉克战争期间".iq"域名被暂停解析一事更被视为美国"悬剑在手"的象征。

2013年斯诺登曝光美国大规模监听后，国际社会对"美国垄断互联网命门"的反弹到达顶点，联合国层面甚至出现推动另建政府主导治理体系的呼声。为消解这一合法性危机、顺应互联网去中心化叙事，奥巴马政府于2014年宣布启动移交程序——将美国商务部对 ICANN 的"合同监管权"解除。2016年3月，ICANN 正式提交脱离美国政府联系的过渡计划。

真正的问题不在"美国是否善良"，而在于：这根命门本来就不该由任何一个国家独握。移交的本质是把制度合法性从"美国庇护下的开放"转向"多方利益攸关体（multi‑stakeholder）自我维持的透明与问责"。但争议也正在于此——保守派担心脱离美国后，ICANN 会被威权国家通过政府咨询渠道逐步蚕食；支持者则认为根服务器的分布式结构和自下而上的共识机制本身就是防火墙。美国让出的不是善意，而是一张越来越护不住的垄断椅子。

新的发展

• DDNS

RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE)

复用 DNS 报文格式，但把 Opcode 设为 5（UPDATE），直接在 UDP/TCP 53 端口上向权威 DNS 服务器发送增删改指令（四段式结构）：

注意：DDNS 本身可以说是一个需求，就是动态调整 DNS，虽然 RFC 2136 经常被称之为 DDNS，但实质是 DDNS 的一种技术方案。
有一些脚本或者路由器插件轮询 IP 然后通过云服务商 API 来动态修改 DNS 记录，在很多场景下也被称之为 DDNS，不要混淆。
云服务商 DNS 都不对外提供 UPDATE 操作，它们通过 HTTP API（IAM/Key 鉴权）来提供 DNS 记录更新。

RFC 2136 DDNS 的典型阵地是你自有/私有部署的受控权威服务器（BIND、PowerDNS、Windows AD DNS、Infoblox 等），其中最常见生产场景是：
客户端发起 DHCP 请求时会带上 hostname（Option 12），DHCP 服务器分配地址后，通过 TSIG/GSS-TSIG 向可写 zone 发 UPDATE，自动注册内部名 A 记录及对应 PTR（反向区也要可被管理）。

• DNSSEC
  安全

• DNSCrypt
  2011 年提出。
  DNSCrypt 在 DNS 请求和解析服务器之间建立加密通信，并验证服务器身份。
  它并非 IETF 标准，但曾经被 OpenDNS 等服务广泛采用。

• DNS over TLS（DoT）
  2016 年成为标准。RFC 7858 Specification for DNS over Transport Layer Security (TLS)
  DNS 全程加密，默认使用 TCP 853 端口。

• DNS over HTTPS（DoH）
  2018 年成为标准。RFC 8484 DNS Queries over HTTPS (DoH)
  特点：

• 基于 HTTPS；
• 默认使用 HTTPS 443 端口；
• 更容易穿透网络限制；

• 可以复用现有 Web 基础设施。

• DNS over QUIC（DoQ）
  RFC 9250。
  基于 QUIC，兼具 UDP 的低延迟和 TLS 的安全性。

• DNS over Tor
  通过 Tor 网络转发 DNS 查询，其主要目标是隐藏客户端来源地址，提高匿名性。
  它不是 DNS 标准协议，而是一种部署方案。

• Oblivious DNS-over-HTTPS（ODoH）
  ODoH 在 DoH 基础上增加代理节点，确保代理服务器看不到查询内容，DNS 服务器看不到客户端 IP，从而进一步提升隐私保护能力。

参考资料与拓展阅读

• https://zh.wikipedia.org/wiki/域名
• https://zh.wikipedia.org/wiki/域名系统
• 阮一峰, DNS 原理入门