DNS简明教程

本文翻译自我的英文博客，最新修订内容可随时参考：DNS简明教程

在我看来，DNS（域名系统）是互联网的核心。我始终认为，控制了DNS就等于控制了网络世界。下面我们就来深入了解DNS。

主机映射表（Hosts）

早期访问计算机需要记住IP地址，但这既难记忆又不便维护（IP变更时需通知所有人）。于是人们创建了一个文件，将计算机名称映射到IP地址，并在所有设备上存储该文件，同时通过一台特定计算机维护更新，这个文件就是hosts（例如：timerring: 88.88.88.88）。这便是ARPANET的起源。

随着互联网发展，IP数量激增，hosts文件变得庞大且容易出现命名冲突，DNS应运而生。

DNS 核心原理

1983年，Paul Mockapetris提出域名系统（DNS），这是一种将域名映射到IP地址的分布式数据库。如今访问网站时，只需向DNS服务器查询域名，即可获取对应IP，不再依赖本地hosts文件（现代计算机的hosts文件通常为空）。

DHCP动态分配

DNS服务器的IP可能是动态的（如家庭宽带），每次联网时由网关通过DHCP（动态主机配置协议）分配。可在Linux系统的/etc/resolv.conf文件中查看当前DNS服务器IP。

DNS协议规则

为确保域名唯一，DNS采用类似现实地址的层级结构（如home.google.com）。

域名层级

1. 根域名（root domain）：以.表示（通常省略），如math.stackexchange.com.末尾的点。
2. 顶级域名（TLD）：如.com、.org。
3. 二级域名（SLD）：用户可注册的域名，如google.com。
4. 主机名（host）：用户自定义的主机标识，如www。

域名资源记录（Resource Record）

每条域名在DNS中对应一条记录，格式为：

域名 生存时间 协议类型 记录类型 值  

• 记录类型（Type）：
  • A：IPv4地址记录（如google.com -> 142.250.78.14）。
  • AAAA：IPv6地址记录。
  • NS：名称服务器记录，指向该层级域名的权威服务器（如.com的NS记录指向.com域的服务器）。
  • MX：邮件交换记录，指定邮件接收服务器（如github.com的MX记录指向其邮件服务器）。
  • CNAME：别名记录，将一个域名指向另一个域名（如blog.timerring.com可能是timerring.github.io的CNAME）。
  • PTR：反向解析记录，将IP映射回域名（用于验证IP所属域名）。

DNS服务器架构

DNS通过域名分区（DNS Zone）实现分布式管理，每个分区有主服务器和从服务器（备份并加速查询），统称为权威服务器（Authoritative Name Servers）。分区存储两类记录：

1. 本分区的域名资源记录（如google.com的A记录）。
2. 父级和子级域名的NS记录（用于层级查询）。

根域名服务器（.) 是DNS的基础，全球共有13组根服务器，可通过root-servers.org查看详情。

eg.undefined

Now every zone has a master server and many slave servers to backup and expedite the query. These servers are called Authoritative Name Servers.

And it save the two types of records:

• This zone's domain name resource records.
• This zone's parent DNS and sub-DNS server records(mainly NS records).

域名解析流程

连接网络时，设备会获取默认DNS服务器（运营商提供或手动设置的公共DNS，如8.8.8.8）。解析过程如下：

1. 本地缓存优先：浏览器和操作系统先检查缓存，若有记录直接返回IP。
2. 递归查询：若缓存无记录，本地DNS服务器向根服务器查询，根服务器返回顶级域名服务器地址（如.com的NS记录），依次递归直至获取目标IP（如www.google.com的解析路径：. -> com -> google.com -> www.google.com）。

缓存机制

为提升效率，浏览器、操作系统和DNS服务器都会缓存解析结果，缓存时间由记录中的Time_to_live（TTL）决定：

• 稳定域名（如google.com）的TTL较长（通常数小时至数天）。
• 动态变更的域名（如临时测试域名）的TTL较短（几分钟至几十分钟）。

DNS泄露与防护

DNS泄露是指DNS请求以明文传输，途经的中间节点可获取用户访问的域名。即使使用代理，未匹配规则的域名仍可能触发本地DNS请求（如浏览器通过WebRTC发送UDP探测包）。

检测工具：

• ipleak.net：通过随机子域名检测DNS请求是否泄露。
• browserleaks.com/webrtc：检测WebRTC是否泄露公网IP。

防护方法：

• DoH（DNS over HTTPS）：通过HTTPS加密DNS请求（端口443）。
• DoT（DNS over TLS）：通过TLS加密DNS请求（端口853）。
• 全局代理模式：将所有流量加密后发送至远程节点处理（如Clash的Fake IP模式）。

完整访问流程示例

以访问google.com为例，整个过程涉及OSI模型的多层协作：

To begin with, you should know the OSI model. I have drawn a good image to explain it. You can also read my previous blog Real Computer Network.undefined

OSI model

因此，请想象一下去冲浪互联网的过程。例如。您在浏览器上查询google.com，然后获取页面，发生了什么？

在常见情况下，当你购买宽带时，运营商会提供一个光纤调制解调器（Fiber-optic Modem），你需要自行购买路由器。路由器通过PPPoE协议连接互联网，获取公共广域网IP（WAN IP，实际仍为内网IP）和DNS服务器IP（通常为两个）。路由器作为本地网络的网关，拥有自己的局域网IP，并通过DHCP协议为设备分配IP地址和DNS服务器地址（通常DNS地址与网关IP均为路由器的本地IP）。

1. 浏览器首先检查自身缓存，查看是否有google.com的IP记录，随后检查操作系统缓存（包括hosts文件中的映射关系）。若均无记录，则发送DNS请求（例如：查询google.com的IP地址）。
2. 传输层：源端口随机（如222），目标端口固定为DNS协议端口53。
3. 网络层：源IP为设备的局域网地址（如192.168.1.10），目标IP为DNS服务器地址（如8.8.8.8）。由于DNS服务器不在本地网络，请求需发送至网关（路由器）。同一网络内通过MAC地址通信，因此进入数据链路层处理。
4. 数据链路层：源MAC地址为设备物理地址（如AA-AA-AA-AA），目标MAC地址通过ARP协议获取，为网关的物理地址（如CC-CC-CC-CC）。
5. 数据帧通过网卡（NIC）发送至物理线路（网线）。
6. 交换机接收数据包并转发至网关（路由器）。
7. 路由器的数据链路层解析出目标MAC为自身，将数据包传递至网络层。由于路由表中无8.8.8.8的路由信息，路由器将数据包发送至公网的默认路由节点。
8. 进入公网前，路由器通过NAT（网络地址转换）将源私有IP转换为自身的公网IP（WAN IP）。
9. 公网中，数据包经多级路由器根据MAC地址转发，直至到达目标DNS服务器。
10. DNS服务器接收数据包，传输层识别目标端口53，解析google.com的IP地址并返回。
11. 响应流程与请求流程相反。最终，设备获取google.com的IP后，通过该IP建立连接获取网页内容，过程与上述类似。

若DNS服务器位于海外，流量需经公共出口（除非使用ISP的IPLC内网专线），可能遭遇以下问题： DNS污染：返回伪造IP地址（tampers a not exist ip）。 TCP重置：中途发送RST包强制中断连接请求（sends the RST packet in advance to reject the connection request）。 IP封禁或主动检测（block ip or active detection）。

实用工具：dig命令

dig是强大的DNS查询工具，常用用法：

• dig baidu.com：查询A记录（等价于dig a baidu.com）。 ;; ANSWER SECTION: baidu.com. 6 IN A 198.18.28.63 ; TTL为6秒，IP为198.18.28.63
• dig +short baidu.com：仅显示IP地址。
• dig @8.8.8.8 baidu.com：指定DNS服务器（如谷歌的8.8.8.8）进行查询。
• dig +trace baidu.com：追踪解析路径，显示从根服务器到目标服务器的查询过程。

;; Received 239 bytes from 198.19.0.3#53(198.19.0.3) in 9 ms  
baidu.com.		6	IN	A	198.18.28.63  ; 最终从c.root-servers.net获取结果  

• dig cname facebook.github.io：查询CNAME记录，显示facebook.github.io指向github.map.fastly.net。

...  

;; ANSWER SECTION:  
facebook.github.io. 3370    IN  CNAME   github.map.fastly.net.  
github.map.fastly.net.  600 IN  A   103.245.222.133  

whois：查询域名注册信息

通过whois命令可获取域名的注册商、过期时间等信息：

whois github.com  ; 注意与系统命令`whoami`（查询当前用户）区分  

参考资料

• RFC 883：DNS协议规范
• 阮一峰：DNS 原理入门
• DNS 解析流程动画演示
• 代理中的DNS泄露分析

通过理解DNS的层级结构、解析流程和安全机制，可更好地优化网络配置、排查访问问题。如需进一步探讨，欢迎访问博客获取最新内容。