DNS是客户端向服务器发送什么，DNS查询请求类型有哪些

DNS是客户端向服务器发送一个域名解析查询请求，本质上是一个标准的DNS查询报文，目的是获取域名对应的IP地址。

很多人第一次接触这个概念时，脑子里会冒出一堆问号：我上网不就是输个网址吗？怎么还要“发请求”？这个请求里到底装了什么东西？别急，我换个说法你就懂了，你打开浏览器输入www.baidu.com，这时候你的电脑就像个迷路的人，站在十字路口问路：“请问www.baidu.com怎么走？”这个“问路”的动作,就是客户端向DNS服务器发送的查询请求。

客户端到底向DNS服务器发送了哪种查询请求

这个问题的答案其实分两种场景：一种是递归查询，另一种是迭代查询，日常上网时，你的电脑作为客户端，通常发出的是递归查询请求，什么意思呢？就是你把问题完全丢给DNS服务器，让它帮你跑腿，最终把准确答案带回来，而DNS服务器之间互相询问时，用的则是迭代查询你让我帮你找，我给你指个路,你自己去问下一家。

在技术层面，客户端发送的是一个DNS查询报文，这个报文被封装在UDP数据报里，默认使用53端口，为什么用UDP而不是TCP？因为UDP快，一个请求一个响应，来回一趟就够了，只有当年响应数据太大、超过512字节时,才会切换到TCP重传。

DNS查询报文里具体装了什么内容

拆开这个报文，你会发现它像一张填好的表格,表格里有这么几个关键字段：

• 事务ID：相当于快递单号，客户端发出去一个请求，服务器回应的响应里必须带着相同的ID,客户端才能对上号。
• 标志位：告诉服务器“我要递归查询”还是“我要迭代查询”，以及“我的请求是标准的还是反向的”。
• 问题部分：这里面才是核心，包括你要查询的域名（比如www.example.com）、查询类型（是查A记录拿IPv4地址，还是查AAAA记录拿IPv6地址，或者是查MX记录拿邮件服务器地址）、查询类别（通常是IN，表示互联网）。

举一个实际例子，你在终端里敲下nslookup www.baidu.com，客户端就会构造这样一个报文：事务ID随机生成，标志位里QR设为0（表示这是查询），RD设为1（要求递归），问题部分写上www.baidu.com，类型为A，类别为IN，然后这个报文从你的电脑出发，发往你在网卡设置里配置的那个DNS服务器，比如电信的

114.114.114或者谷歌的8.8.8。

客户端发送请求时用的是源端口还是固定端口

这里有个小细节很多人搞混：客户端发送DNS查询时，不是从源端口53发出的，客户端会随机生成一个大于1024的临时端口，比如54321，然后目的端口写53，发给DNS服务器，服务器收到后，把响应报文的目的端口改成54321，源端口写成53，原路返回，这个过程可以用抓包软件看得一清二楚，你打开Wireshark，过滤udp.port == 53,就能看到请求和响应一对一对地出现。

常见的DNS查询类型有哪些场景区别

不同场景下，客户端发送的查询类型完全不同，理解这个,你就知道为什么有时候域名能开网页却收不到邮件。

A记录和AAAA记录：最普通的“查地址”

咱们平时访问网站，客户端发送的就是A记录查询，把域名翻译成IPv4地址，如果你的网络环境已经升级到IPv6，那客户端会尝试发送AAAA记录查询，把域名翻译成IPv6地址，这也是为什么有些老设备访问纯IPv6网站会失败因为设备发出的查询请求里只写了A，没写AAAA,服务器就算有IPv6地址也不给你。

CNAME和MX记录：换个名字，找邮件服务器

当你在浏览器里输入www.taobao.com时，客户端发送的查询可能是A记录，但返回的答案里可能会附带一个CNAME记录，告诉你“这个域名的真名其实是www.taobao.com.cname.cloudfront.net”，然后客户端还得再发一次A记录查询去问那个真名的IP，至于邮件，你在配置邮箱客户端时，客户端会发MX记录查询，问qq.com的邮件服务器是哪台，拿到类似mx.qq.com的答案后,再去查它的A记录。

反向查询和NS查询：从IP找域名，从顶级域找授权

有一种特殊场景，叫反向DNS查询（PTR记录），比如你用nslookup 8.8.8.8，客户端发送的报文里问题部分写的是8.8.8.in-addr.arpa，类型是PTR，意思就是问“这个IP对应的域名是什么”，这种查询在邮件反垃圾验证里很常用，还有一种NS查询，当客户端配置了根服务器地址时，会向根服务器发NS查询，问“.com这个顶级域归谁管”，然后根服务器返回一串.com服务器的名字和IP。

当客户端发送请求后，DNS服务器如何一步步回应

理解了“发什么”，你还得知道“发去哪儿”和“怎么回”，整个过程像接力跑，但客户端实际打交道的第一站,就是本地DNS服务器。

第一步：查本地缓存和hosts文件

客户端发送查询请求之前，其实会先翻自己家里的抽屉本地DNS缓存和hosts文件，如果命中了，根本不会发请求到外部，只有没找到时，客户端才会构造报文，发送给配置的DNS服务器，这一步很多人会在排查“DNS是客户端向服务器发送什么”时忽略，实际上客户端发的第一个请求，有时候是发给自己的系统服务,而不是真的广播出去。

第二步：本地DNS服务器的递归查询之旅

假设你发给了114.114.114，这台服务器看到你的请求里RD标志位是1，就知道你想让它全权代理，它会先查自己的缓存，如果没有，就代替你向根服务器发迭代查询，根服务器返回.com服务器的地址，它再向.com服务器发查询，后者返回baidu.com的权威服务器地址，最后它再向权威服务器发一次查询，拿到www.baidu.com的IP，在这个过程中，本地DNS服务器作为客户端，发送的是迭代查询请求，而最终答案拿到后，它会用我们最开始说过的那个事务ID,把响应返回给你的电脑。

第三步：响应报文里除了IP还有什么

响应报文里除了你想要的IP地址，还带着TTL值（生存时间，告诉你这个记录能缓存多久）、权威标记（表示这个答案是不是权威服务器直接给的）以及可能附加的额外记录，这些信息同样重要,比如TTL值决定了你本地DNS缓存多久刷新一次。

排查故障时怎么确认客户端发送的请求是否正确

当你的网站打不开，或者邮箱发不出去，很多人第一反应是“DNS解析慢”，但如果你能看懂客户端发送的请求,问题能解决一半。

用dig命令查看完整请求过程

在Linux或macOS的终端里输入：

dig www.baidu.com +trace

这个命令会把客户端请求的每一跳都列出来，你会看到第一步发送到根服务器，然后依次到.com服务器、baidu.com权威服务器，每个步骤里都有QUERY部分，里面详细记录了你发送的域名、类型、类别，如果你发现QUERY部分显示的域名和你输的不一样，那多半是浏览器帮你加了什么前缀,或者你中了运营商DNS劫持。

用nslookup手动模拟客户端请求

Windows上也一样，输入nslookup进入交互模式，然后输入set type=MX，再输入域名，就能看到客户端发送的MX查询请求，如果你设置set debug，还能看到完整的响应报文字段,这套操作在排查邮件服务器配置时特别好用。

为什么有时候改了DNS解析，网页还是旧IP

这就涉及到客户端的缓存策略，你发的请求本身没问题，但本地DNS服务器可能把旧记录缓存了，这时候你可以用ipconfig /flushdns（Windows）或者sudo systemd-resolve --flush-caches（Linux）强制清空本地缓存，然后再发一次请求,就能拿到新IP了。

关于DNS发送请求的常见误解和疑问解答

围绕“DNS是客户端向服务器发送什么”，不少人有几个典型困惑,我们挑两个最常见的说清楚。

浏览器里的地址栏输入IP地址，还会发DNS请求吗

不会，你在地址栏直接敲http://192.168.1.1，客户端会识别出这是合法的IP格式，直接跳过DNS解析步骤，不会构造任何DNS请求报文，这也是判断你是否需要排查DNS问题的一个简单方法：如果IP能打开，域名打不开,那么问题就出在DNS解析环节。

手机连接Wi-Fi后，客户端发送的DNS请求和电脑一样吗

流程一样，区别在于手机可能会通过DHCP从路由器获取DNS服务器地址，而路由器本身又作为DNS转发器，所以手机发出一笔请求，实际上是先发给了路由器（比如168.1.1），路由器再作为客户端向上游运营商服务器发送同样的查询请求,整个过程请求报文的内容结构完全一致。

短网址和二维码扫描时，DNS请求有什么特殊之处

没有特殊，你扫二维码打开一个短链接，首先浏览器还是发送一个A记录查询，拿到短网址服务的服务器IP，然后服务器返回302跳转，你的浏览器再对新跳转的域名发起另一次DNS请求，所以本质上还是客户端向DNS服务器发送域名解析查询请求,只不过请求的次数从一次变成了两次。

说到底，DNS的运作逻辑并不复杂，你的客户端永远扮演“提问者”的角色，向服务器发送结构明确的查询报文，服务器则在层层递进中把答案拼凑完整，最后原路返回，下次你遇到网页打不开，不妨先想想这个报文有没有正确发出去，目的地对不对，答案有没有被缓存，掌握了这一点,你就已经超越了相当一部分自称懂网络的人。