DNS 域名解析
DNS(域名系统)是互联网将域名转换为IP地址的核心服务。其解析过程包括:本地缓存检查→递归查询→迭代查询(根→顶级→权威服务器)。DNS报文由Header、Question、Answer等5部分组成,通过标志位区分权威/非权威响应。实际解析中常使用CNAME别名(如baidu.com指向a.shifen.com)和负载均衡。全球13组根服务器通过任播技术部署,与顶级域(.com/.cn)、二级域
目录
DNS 是什么
DNS(Domain Name System,域名系统)是互联网的一项核心服务,主要作用是将可读的域名(如 www.google.com)转化为机器可识别的 IP 地址(142.250.191.100)
也就是说,当我们在浏览器中输入一个网址(URL)时,计算机并不知道这个网站在哪里,而是需要通过 DNS 查询该域名对应的 IP 地址,才能建立连接、加载网页
过程如下:
访问 www.google.com → DNS 查出它实际的 IP 地址(如 142.250.191.196)→ 浏览器通过这个 IP 地址连接服务器 → 显示网页内容
DNS 报文结构
无论查询(Query)还是响应(Response),DNS 报文都由以下 5 个部分组成:
每个部分都是可选的(除了 Header),具体是否出现取决于报文类型(查询/响应)和内容
我们先来看 Header
Header
ID(2字节):由客户端随机生成,用于匹配 "请求-响应",服务器原样返回,客户端靠它知道哪个响应对应哪个请求
Flags(标志位)(2字节):
位 | 名称 | 含义 |
0 |
QR |
0=查询(Query),1=响应(Response) |
1-4 |
Opcode |
操作码,0=标准查询,1=逆查询(IP -> 域名,已被废弃),2=服务器状态请求 |
5 |
AA |
Authoritative Answer,权威应答(仅响应中有效) |
6 |
TC |
Truncated,报文被截断(通常因 UDP >512 字节) |
7 |
RD |
Recursion Desired,客户端希望服务器递归查询 |
8 |
RA |
Recursion Available,服务器支持递归查询 |
9-11 |
Z |
保留位,必须为 0 |
12-15 |
RCODE |
响应码:0=无错误,1=格式错误,2=服务器失败,3=域名不存在,4=不支持查询类型,5=拒绝 |
其中,AA(权威应答)= 1 时:
表示当前 DNS 应答报文是由“权威域名服务器”返回的,该服务器对所查询的域名区域具有管理权,其提供的数据是权威、可信的
权威域名服务器
权威域名服务器是指负责管理某个特定域名区域(Zone)的 DNS 服务器
例如:
example.com 的权威域名服务器可能为 ns1.example.com 、ns2.example.com
当查询 www.example.com 的 A 记录时,只有这些权威服务器返回的结果才带有 AA=1,权威服务器的数据来源于域名管理员配置的“区域文件(Zone File)”,是最原始、最准确的数据
而当 AA = 0 时:
表示该应答来自非权威服务器,如 本地 DNS 缓存服务器(如运营商 DNS、8.8.8.8)、递归解析器(Resolver)、中间缓存服务器,它们的数据是“从别处查来并缓存的”,不是原始数据源,这类应答可能过期(取决于 TTL),不一定最新
QDCOUNT / ANCOUNT / NSCOUNT / ARCOUNT(各 2 字节):表示后续各部分包含的记录条数
例如:
;; ANSWER SECTION:
www.baidu.com. 300 IN A 180.101.49.12
www.baidu.com. 300 IN A 180.101.49.11
此时 ANCOUNT = 2(两条 A 记录)
Question(问题部分)
用于告诉服务器"你想查什么":
QNAME(域名):使用“标签长度+内容”格式编码,以 0x00 结尾
例如:www.example.com 编码为:
0x03 'w' 'w' 'w' 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0x03 'c' 'o' 'm' 0x00
↑长度 ↑字符 ↑长度 ↑字符... ↑长度 ↑字符 ↑结束
支持“消息压缩”(使用指针指向之前出现的相同域名,节省空间),例如 0xC0 0x0C 表示“指向报文偏移量 0x0C 处的域名”
QTYPE(查询类型)(2字节):
值 | 类型 | 说明 |
1 |
A |
IPv4 地址 |
2 |
NS |
域名服务器 |
5 |
CNAME |
别名 |
15 |
MX |
邮件服务器 |
28 |
AAAA |
IPv6 地址 |
255 |
ANY |
所有记录 |
QCLASS(查询类别)(2字节):用于指定 查询的网络类别或命名空间,通常为 1
1 -> IN:Internet(互联网),绝大多数 DNS 查询都使用这个类别,用于 IPv4/IPv6 域名解析、邮件路由等)
其他值如:
2-> CS:CSNET class(已废弃)—— 早期 CSNET 网络使用,现已不用
3 -> CH:CHAOS(混沌类)—— 用于 Chaosnet 协议,现代极少使用,有时用于版本查询
Resource Record(资源记录)
Answer/Authority/Additional,这三个部分结构完全相同,每条记录称为一个 RR(Resource Record),且 只有应答报文(Response)才包含 Answer/Authority/Additional 部分,查询报文(Query)中这些部分为空
NAME(域名):使用和 QNAME 相同的“标签+长度”格式,支持指针压缩
TYPE/CLASS:同 QTYPE / QCLASS
TTL(Time To Live):该记录在缓存中可保存的秒数,例如:300 = 5 分钟,86400 = 1 天
RDATA(资源数据):根据 TYPE 不同,内容格式不同
TYPE | RDATA 格式示例 |
A |
4 字节 IPv4 地址 → |
AAAA |
16 字节 IPv6 地址 |
CNAME |
压缩格式域名 → 指向 |
NS |
压缩格式域名 → |
MX |
2 字节优先级 + 域名 → |
TXT |
长度+字符串 → |
Answer
回答部分,对查询问题的直接答案 —— 即你查询的记录类型所对应的资源记录
包含与查询匹配的记录,如 IP 地址(A、AAAA)、别名(CNAME)、邮箱服务器(MX)等
例如:
;; ANSWER SECTION:
www.baidu.com. 300 IN A 180.101.49.12
www.baidu.com. 300 IN A 180.101.49.11
Authority
授权部分,提供“谁是权威”的信息,通常用于指示“该域由哪些权威服务器管理”或“用于缓存控制的 SOA 记录
包含 NS(Name Server)记录 → 告诉你“这个域名该问谁”、SOA(Start of Authority)记录 → 用于负缓存(Negative Caching)时告知 TTL
例如:
当域名不存在时,就返回:
;; AUTHORITY SECTION:
example.com. 900 IN SOA ns1.example.com. admin.example.com. ( ... )
告诉你“这个域归谁管 + 负缓存时间”
Additional
:附加部分,提供“额外有用信息”,帮助客户端减少后续查询,提升效率。不是必须的,但能优化性能,包含 NS/MX 附带 IP、EDNS 扩展支持等
例如:
胶水记录(Glue Records):当 Authority 或 Answer 中包含域名(如 NS 或 MX),附加部分可提供这些域名的 IP 地址,避免客户端再次查
;; ANSWER SECTION:
example.com. 172800 IN NS ns1.example.com.
example.com. 172800 IN NS ns2.example.com.;; ADDITIONAL SECTION:
ns1.example.com. 172800 IN A 192.0.2.10
ns2.example.com. 172800 IN A 192.0.2.20
客户端拿到 NS 后,直接用附加的 A 记录连接,无需再查 ns1.example.com 的 IP
总而言之,Answer 是“你要的答案”,Authority 是“谁管这事”,Additional 是“顺手给你的小抄”
Answer Section:核心答案,直接回应查询
Authority Section:用于错误处理、委派、缓存控制
Additional Section:性能优化神器,减少 DNS 查询轮次,支持现代扩展(如 CDN、DNSSEC)
接下来,我们通过 Wireshark 抓包来看实际的 DNS 报文
抓包分析
我们以查询 AAAA www.baidu.com 地址为例
请求
可以看到 DNS 的传输协议为 UDP:
源端口:62277(客户端随机端口)
目的端口:53(标准 DNS 端口)
UDP 长度:39 字节(包含 UDP 头 + DNS 数据)
我们重点来看 DNS 层:
Header 部分:
Transaction ID:0x83ee(十进制:33758),用于匹配请求与响应(后续响应中会相同)
Flags:0x0100,二进制为 0000 0001 0000 0000:
QR=0:这是 查询(Query),不是响应
Opcode=0:标准查询(Standard Query)
AA=0:非权威应答
TC=0:未截断(响应不会被截断)
RD=1:递归查询(希望 DNS 服务器帮你查)
RA=0:无意义(查询中为 0)
AD=0,CD=0:无 DNSSEC 认证/检查(普通查询)
因此,这是一个 标准、递归、非权威的 DNS 查询请求,希望 DNS 服务器“帮我查到底”,并返回结果
Questions:1,即 查询一个域名
Answer RRs:0,没有答案(因为是请求)
Authority RRs:0,没有授权记录
Additional RRs:0,没有附加记录
Queries(问题部分):
www.baidu.com: type AAAA, class IN
QNAME:www.baidu.com,要查询的域名(结尾点省略了)
QTYPE:AAAA,查询 IPv6 地址
QCLASS:IN,Internet 类别(默认,通常省略)
即,用户正在尝试通过 IPv6 访问百度网站
我们继续看响应
响应
Wireshark 显示 [Response In: 518],即 响应在 Frame 518 中:
Header:
Transaction ID:0x83ee,与请求完全一致,确认是对应响应
Flags:0x8180
按位分解:
位 | 名称 | 值 | 说明 |
15 |
QR |
1 |
这是响应(Response) |
14-12 |
Opcode |
0 |
标准查询(Standard Query) |
11 |
AA |
0 |
非权威应答—— 该服务器不是 baidu.com 的权威服务器(如递归解析器) |
10 |
TC |
0 |
消息未截断(完整响应) |
9 |
RD |
1 |
请求递归(客户端希望递归查询) |
8 |
RA |
1 |
递归可用(Recursion Available)—— 服务器支持递归查询 |
7 |
Z |
0 |
保留位 |
6 |
AD |
0 |
回答未认证(无 DNSSEC 验证) |
5 |
CD |
0 |
不检查(Check Disable) |
4-0 |
RCODE |
0 |
无错误(No error) |
即,这是一个成功的、非权威的 DNS 响应,由递归 DNS 服务器返回,支持递归查询,但未启用 DNSSEC
Questions:1,查询一个域名
Answer RRs:3,返回了 3 条答案记录
Authority RRs:0,没有授权记录
Additional RRs:0,没有附加记录
Questions:
www.baidu.com: type AAAA, class IN,与请求一致,确认是针对 www.baidu.com 的 AAAA 查询
Answer(回答部分):
其中,第一条 —— CNAME 记录:
www.baidu.com: type CNAME, class IN, cname www.a.shifen.com
CNAME 值 为 www.a.shifen.com,表示 www.baidu.com 是一个别名,实际指向的是 www.a.shifen.com
也就是说,www.baidu.com 只是一个别名,而 www.a.shifen.com 才是百度的 真实服务器入口
其中 shifen.com 是百度公司注册并管理的域名,主要用于承载百度搜索、百度首页等核心服务的后端服务器集群,通过 CNAME 从 baidu.com 域名指向 shifen.com,从而实现:
1. 统一管理:所有百度子域名(如 tieba.baidu.com、map.baidu.com)都可以 CNAME 到不同的 shifen.com 子域,集中管理后端 IP
2. 负载均衡:www.a.shifen.com 可返回多个 IP(A/AAAA),实现智能调度和负载分担
3. CDN/ 高可用:shifen.com 后端可接入 CDN、反向代理、异地多活架构,提升访问速度和稳定性
4. 快速切换:若某机房故障,只需修改 shifen.com 的解析,无需动 baidu.com 主域
5. 隐藏架构:用户看到的是 baidu.com,实际访问的是 shifen.com,增强安全性和灵活性
第二条 —— AAAA 记录:
www.a.shifen.com: type AAAA, class IN, addr 2409:8c00:6c21:11eb:0:ff:b0bf:59ca
查询出 www.a.shifen.com 的地址为 2409:8c00:6c21:11eb:0:ff:b0bf:59ca,这是一个有效的 IPv6 地址,属于百度的公网 IP 段
第三条 —— AAAA 记录:
www.a.shifen.com: type AAAA, class IN, addr 2409:8c00:6c21:118b:0:ff:b0e8:f003
www.a.shifen.com 的地址为 2409:8c00:6c21:118b:0:ff:b0e8:f003,是 www.a.shifen.com 的另一个 IPv6 地址
因此,其整体解析过程为:
接下来,我们继续来学习 DNS 的层级架构
DNS 层级结构
DNS 采用 树状结构 来组织和管理全球的域名,这种结构使得域名解析高效、可扩展、分布式管理:
每一层都由不同的权威 DNS 服务器 负责管理,解析时从根开始逐级委托,最终找到目标 IP
我们分别来看每一层
根域(Root Zone)
表示整个 DNS 树的起点,由 13 组根服务器(逻辑上,实际有数百个镜像节点)负责管理,分布在全球,根服务器不直接解析域名,只告诉查询者“去问哪个顶级域服务器”
这 13 组根域名服务器由不同的运营机构负责:
名称 | 运营机构 | 国家/地区 | 备注 |
A |
Verisign |
美国 |
同时运营 .com/.net,全球节点最多 |
B |
USC-ISI |
美国 |
南加州大学信息科学研究所 |
C |
Cogent Communications |
美国 |
商业 ISP |
D |
University of Maryland |
美国 |
马里兰大学 |
E |
NASA |
美国 |
美国宇航局 |
F |
Internet Systems Consortium (ISC) |
美国 |
开源组织,也运营 F-Root 和 BIND 软件 |
G |
Defense Information Systems Agency (DISA) |
美国 |
美国国防部 |
H |
U.S. Army Research Lab |
美国 |
美国陆军实验室 |
I |
Netnod |
瑞典 |
欧洲首个根服务器运营方 |
J |
Verisign |
美国 |
同 A,但独立部署 |
K |
RIPE NCC |
荷兰 |
欧洲 IP 地址注册机构 |
L |
ICANN |
美国 |
互联网名称与数字地址分配机构(管理整个 DNS 体系) |
M |
WIDE Project |
日本 |
亚洲首个根服务器,由日本 WIDE 项目运营 |
每组根服务器都有唯一的 IPv4 和 IPv6 地址,虽然大部分在美国,但通过 Anycast 技术,每组都在全球部署了数百个镜像节点
Anycast
任播(Anycast) 是一种网络寻址和路由策略,允许多个地理位置不同的服务器使用相同的 IP 地址,客户端请求会被路由到“最近”或“最优”的一个节点,其核心思想是:一个 IP,多个位置,路由决定谁响应
单播 vs 广播 vs 组播 vs 任播:
类型 |
目标数量 |
说明 |
示例 |
单播(Unicast) |
1 个 |
一对一通信 |
访问某台特定服务器 |
广播(Broadcast) |
所有 |
一对所有(局域网内) |
ARP 请求 |
组播(Multicast) |
多个(订阅者) |
一对多(特定组) |
视频会议、IPTV |
任播(Anycast) |
多个(但只响应一个) |
一对最近(路由决定) |
DNS 根服务器、CDN、DDoS 防护 |
客户端无感知,自动连接到最近节点:
多个服务器配置相同的公网 IP 地址
通过 BGP (边界网关协议,负责在自治系统(AS)之间交换路由信息)向互联网宣告该 IP
路由器根据 "最短路径"(AS Path、Metric 等)选择最优节点
客户端请求主动被导向 最近/最优节点
例如:访问 8.8.8.8,但不知道背后是哪个数据中心:
客户端 A(北京) → 路由器 → 最近节点:北京服务器(8.8.8.8)
客户端 B(纽约) → 路由器 → 最近节点:纽约服务器(8.8.8.8)
客户端 C(伦敦) → 路由器 → 最近节点:伦敦服务器(8.8.8.8)
所有服务器 IP 都是 8.8.8.8,但物理位置不同
也就是说,每个 "根服务器"(如 a.root-servers.net),在全球有多个物理服务器,共享同一个 IP,当用户访问时,网络自动路由到地理位置最近/延迟最低的节点
那么,为什么是 13 组,不能更多吗?
这是一个历史性设计限制:
DNS 响应最初限制在 512 字节 UDP 包内(RFC 1035),根服务器的 NS 记录 + 对应的 A 记录必须能装进一个包,因此,计算后,最多能容纳 13 组服务器的信息地址
所以,13 是逻辑名称的限制,而不是技术瓶颈
根域文件包含内容:.com 由哪些服务器负责,.cn 由哪些服务器负责,如:
.com 的 NS 记录:
a.gtld-servers.net.
b.gtld-servers.net.
...
对应的 A 记录:
a.gtld-servers.net. → 192.5.6.30
b.gtld-servers.net. → 192.33.14.30
...
例如:当查询 www.example.com 时,首先需要查询 .com 的域名服务器地址,向根服务器查询,根服务器就会返回 .com 的顶级域服务器地址
顶级域(Top-Level Domain,TLD)
位于根域之下,如 .com, .org, .net, .cn, .jp, .edu, .gov, .io
由不同的机构管理:
.com:Verisign(美国公司)
.cn:CNNIC(中国互联网络信息中心)
.edu:EDUCAUSE(美国高等教育信息化联盟)
......
TLD 服务器不解析具体网站,只告诉查询者“example.com 的权威服务器是谁”
例如:.com 服务器会返回 example.com 的权威 DNS 服务器(如 ns1.example.com)
二级域(Second-Level Domain,SLD)
用户注册的“主域名”,如:example.com、baidu.com、wikipedia.org
由域名注册商(如 GoDaddy、阿里云、腾讯云)协助用户设置,用户可以在此层级设置权威 DNS 服务器(NS 记录),比如
example.com 的 NS 记录:
ns1.example.com
ns2.example.com
或使用云服务商 DNS:
ns1.alidns.com
dns10.hichina.com
这一层开始,域名所有者可以完全控制解析记录(A、CNAME、MX、TXT 等)
子域/主机(Subdomain/Host)
在二级域下创建的子域名或主机名,如:
www.example.com
mail.example.com
api.example.com
blog.example.com
......
由二级域的权威 DNS 服务器负责解析,可设置 A 记录(IP)、CNAME(别名)、MX(邮件)等
接下来,我们就可以来看 DNS 是如何解析域名的了
DNS 工作流程
我们仍以访问 www.baidu.com 为例
检查本地缓存
1. 浏览器先查看自己是否缓存过该域名的 IP,若已有缓存,则直接使用缓存中的 IP 地址
例如:Chrome 查看 DNS 解析缓存:
2. 若缓存中没有,应用程序会调用 系统 DNS 解析接口,操作系统 DNS 客户端服务(Dnscache)介入,检查本地 DNS 缓存
windows 可通过 ipconfig /displaydns 查看本地 DNS 缓存:
3. 此外,系统还会检查本地的 hosts 文件(如:C:\Windows\System32\drivers\etc\hosts),查看是否有手动绑定的 IP
上述过程中,一旦找到,则直接使用,解析结束
若未找到,则进入下一步 —— 向 DNS 服务器发起请求
向 DNS 服务器发起请求
DNS 解析器向配置的 本地 DNS 服务器(如 运营商 DNS、、公共 DNS 8.8.8.8、114.114.114.114)发送查询请求)
这个 DNS 服务器通常由你的 ISP(网络运营商)自动分配,也可以手动设置(如改用 Cloudflare 的 1.1.1.1)
在网络设置中:
自动(DHCP)表示设备通过 DHCP 协议自动获取 DNS 服务器地址
当设备连接到一个网络(如 Wi-Fi 或有线网络)时,DHCP 服务器会为你分配 IP 地址、子网掩码、网关,以及 DNS 服务器地址,"自动" 意味着你不需要自己输入 DNS(如 8.8.8.8),系统会从网络中的 DHCP 服务器获取
例如:
1. 设备连接到网络(例如家里的 Wi-Fi)
2. 发起 DHCP 请求(DHCP Discover)
3. 路由器(或 DHCP 服务器)响应(DHCP Offer)(包含内容 IP 地址、子网掩码、默认网关、DNS 服务器地址(如 192.168.1.1 或 114.114.114.114))
4. 设备接收并配置这些参数
本地 DNS 服务器接收到请求后,就会去寻找答案,然后再返回结果
DNS 服务器迭代查询
本地 DNS 服务器开启 "迭代查询",逐级询问:
1. 问根域名服务器(Root DNS Server)
全球有 13 组 根服务器(集群,分布在世界各地)
本地 DNS 询问根服务器: " .com 顶级域名的服务器在哪?"
根服务器返回 .com 顶级域名的服务器地址
2. 问顶级域名服务器(TLD Server)
本地 DNS 继续问 .com 的 TLD 服务器:" baidu.com 的权威 DNS 服务器在哪?"
TLD 服务器返回 baidu.com 的权威域名服务器地址
3. 问权威域名服务器(Authoritative DNS Server)
本地 DNS 最后去问 baidu.com 的权威服务器:“请告诉我 www.baidu.com 的IP 是多少?"
权威服务器查找自己的区域文件(zone file),找到 www 的 A 记录(如 39.156.70.239),返回这个 IP 地址给本地 DNS 服务器
4. 本地 DNS 服务器返回结果并缓存
本地 DNS 服务器拿到 www.baidu.com → 39.156.70.239 后,将结果返回给浏览器,同时在本地缓存这个记录(根据TTL 时间,比如 300 秒),下次有人问就直接返回,不用再查
浏览器在拿到 IP 地址 39.156.70.239 后,后续就会继续 发起 TCP 连接、发送 HTTP/ HTTPS 请求、服务器响应......
总体流程
详细解析过程
接下来,我们通过命令行(nslookup)来模拟一下本地 DNS 服务器后续的解析过程:
查询根域名服务器 → 返回根域名服务器地址
↓
[根服务器] 查询 .com 服务器→ 返回 .com TLD 服务器地址
↓
[.com TLD 服务器] 查询 baidu.com 权威服务器地址 → 返回 baidu.com 权威服务器地址
↓
[权威 DNS 服务器] 查询 www.baidu.com 服务器地址 → 返回 www.baidu.com 的 IP
查看 DNS 的根服务器:
启动 nslookup 进入交互模式,使用 set type=ns 设置查询类型为 NS(Name Server)记录,查询 根域 .:
其中第一部分为非权威应答(Non-authoritative answer):使用当前 DNS 服务器(192.168.173.176)返回的根服务器列表,它不是根服务器本身,而是从缓存或上游 DNS 获取了这些信息,所以是 非权威应答(Non-authoritative)
第二部分为 IPv6 地址:显示了部分根服务器的 IPv6 地址(AAAA 记录)
接着,我们选择一个根服务器进行通信,并向该根域名服务器咨询 .com 域名服务器的地址:
此时,返回了 .com 的顶级域的权威 DNS 服务器列表,因为我们直接查询的是 根服务器,它在根区(Root Zone)中存储了 .com、.org 等顶级域名 NS 记录,它的 NS 查询具有权威性
其中,gtld 即 Generic Top-Level Domain,通用顶级域名,是互联网上最常见、最商业化的域名后缀(如 .com, .org, .app),由全球性机构管理,面向公众开放注册,是 DNS 体系中根服务器直接管辖的核心部分
TLD 类型:
类型 | 全称 | 中文 | 示例 | 管理机构 |
gTLD |
Generic Top-Level Domain |
通用顶级域 |
|
ICANN 授权注册局(如 Verisign、Public Interest Registry) |
ccTLD |
Country Code Top-Level Domain |
国家/地区代码顶级域 |
|
各国 NIC(如 CNNIC、JPNIC) |
sTLD |
Sponsored Top-Level Domain |
赞助型顶级域(部分归类为 gTLD) |
|
特定机构管理(如 Educause) |
Infrastructure TLD |
基础设施顶级域 |
基础设施专用 |
|
IETF / IANA |
常见 gTLD:
.com:商业(最主流)
.org:非营利组织
.net:网络服务
.app:应用程序
.ai:人工智能
.io:技术/游戏
我们继续从中选择一个服务器进行通信,并咨询 baidu.com 的域名服务器地址:
可以看到,baidu.com 的权威 DNS 服务器有 5个(ns1~ns7),这些域名各自对应着多个 IP 地址,我们仍然随机选择一个,并咨询 www.baidu.com 的 IP 地址:
此时我们可以看到一条 CNAME 结果,也就是说 www.baidu.com 是一个别名,实际指向的是 www.a.shifen.com,因此,我们需要得到 www.a.shifen.com 的 IP 地址:
此时返回了 a.shifen.com 的 5 个权威 DNS 服务器及其 IP 地址,我们再从中选择一个,查询 www.a.shifen.com 的地址:
此时返回的结果,就是我们需要的 www.a.shifen.com 的 IP 地址
我们再总结一下上述流程:
用户 → 本地 DNS → 根服务器 → .com 权威服务器 → baidu.com 权威服务器 → a.shifen.com 权威服务器 → 最终 IP
更多推荐
所有评论(0)