目录
DNS 协议报文格式
Identification 会话标识(2 字节)
是 DNS 报文的 ID 标识,对于请求报文和其对应的应答报文,这个字段是相同的,通过它可以区分 DNS 应答报文是哪个请求的响应。
Flags 标志(2 字节)
四大区域长度(8 字节)
- Questions(2 字节):表示查询问题区域的数量。
- Answers(2 字节):表示查询应答区域的数量。
- Authority(2 字节):表示授权区域的数量。
- Additional Information(2 字节):表示附加信息区域的数量。
Questions 查询问题区域(不定长)
- 查询名:长度不固定,且不使用填充字节,一般该字段表示的就是需要查询的域名(如果是反向查询,则为 IP,反向查询即由 IP 地址反查域名),一般的格式如下图所示。
-
查询类型:
-
查询类:通常为 1,表明是 Internet 数据。
Answers 查询应答区域(不定长)
-
查询名、查询类型、查询类 和 Questions 查询问题区域一致。
-
生存时间(TTL):以秒为单位,表示的是资源记录的生命周期,一般用于当地址解析程序取出资源记录后决定保存及使用缓存数据的时间,它同时也可以表明该资源记录的稳定程度,极为稳定的信息会被分配一个很大的值(比如:86400,这是一天的秒数)。
-
资源记录长度:指示资源记录的长度。
-
资源记录:可变长字段,表示按照查询段的要求返回的相关资源记录的数据。可以是 IP Address(表明查询问题报文想要的回应是一个 IP 地址)或者 CNAME(表明查询问题报文想要的回应是一个规范主机名)等。
Wireshark 抓包分析
下面对 jocent.me 进行域名解析。
- DNS Query Request:
DNS Query Response:
DNS 协议实现方式
DNS over UDP/TCP
常见的 DNS 服务器都是以 UDP 作为主要传输层协议的。但实际上,DNS 不仅使用了 UDP 协议,也使用了 TCP 协议。例如:DNS 查询的类型不止包含 A 记录、CNAME 记录等常见查询,还具有 AXFR 类型的特殊查询,这种特殊查询主要用于 DNS 区域传输,它的作用就是在多个命名服务器之间快速迁移记录,由于该场景对数据的准确有着较强的需求,查询返回的响应也比较大,所以会使用 TCP 协议来传输数据包。
UDP:传输小数据 DNS 报文
使用 TCP 协议完成一次 DNS 查询共需要 330 字节的流量,包括:
- 三次握手 TCP 流量:L2(14x3)+ L3(20x3)+ TCP(44+44+32)字节。
- DNS 查询协议头流量:L2(14)+ L3(20)+ TCP(20)字节
- DNS 响应协议头流量:L2(14)+ L3(20)+ TCP(20)字节
使用 TCP 协议完成一次 DNS 查询只需要 84 字节的流程,包括:
- DNS 查询协议头流量:L2(14)+ L3(20)+ UDP(8)字节
- DNS 响应协议头流量:L2(14)+ L3(20)+ UDP(8)字节
需要注意的是,上述计算是忽略了 DNS 递归查询的理想状态下进行的,实际上递归查询会显著放大 TCP 协议在 DNS 场景中的额外开销。
TCP:传输大数据 DNS 报文
随着 DNSSEC 等机制的引入,复杂场景中的 DNS 报文也变得越来越大,理论上最大可达到 64KB。此时的 DNS 报文就需要面对 MTU(通常为 1500B)分片和重组的问题。所以在大数据 DNS 报文传输场景中,TCP 协议又成为了一个好的选择。
同时,当 DNS 数据包变得足够大时,那么 TCP 三次握手带来的额外开销也变得不那么显眼了。
- 当 DNS 数据包大小为 500 字节时,TCP 协议的额外开销为 ~41.2%;
- 当 DNS 数据包大小为 1100 字节时,TCP 协议的额外开销为 ~20.7%;
- 当 DNS 数据包大小为 2300 字节时,TCP 协议的额外开销为 ~10.3%;
- 当 DNS 数据包大小为 4800 字节时,TCP 协议的额外开销为 ~5.0%;
DNS over HTTP
随着 TCP 协议的引入变得可以接受,那么更灵活的 HTTP 协议被引入也是水到渠成。DNS over HTTP 最大的特点在于可以绕开电信运营商 Local DNS 服务器的解析,主要的应用场景在为 APP 类或桌面应用提供服务,如:游戏、电商、金融、音视频、社交类 APP。
DNS 缓存在 DNS 系统大量的使用,在提升用户域名访问体验中发挥了重要作用。但值得注意的是,在实际生产中,Local DNS 缓存往往不受用户自己控制,可能会出现 Local DNS 缓存刷新和自身业务 IP 地址变更需求响应时间存在差距的问题。
HTTP DNS 优点:
- 绕过运营商 Local DNS,自己控制。
- 能直接获取到客户端 IP 地址,更精准的返回结果,避免跨运营商。
- 无运营商缓存,域名变更快速生效。
- HTTP DNS 可以在终端 APP DNS 缓存超时之前提前进行解析,规避了缓存再解析导致延时的问题。
- 复用 HTTPS 的安全性,预防 DNS 劫持。
- 客户端通过 HTTP/HTTPs 协议向 HTTP DNS 集群发起查询请求,携带用户域名和终端 IP。
- 服务集群查询 CDN 内部调度系统,将域名最佳访问节点 IP 响应给客户端。
- 客户端收到响应结果向节点发起请求。
- 客户端拿到最优 IP 后,发起业务访问。
- 若客户端访问 HTTP DNS 集群失败,可自动切换为传统方式通过运营商 Local DNS 进行解析查询。
HTTP DNS 的不足在于需要 APP 加载相应的 SDK 对默认的操作系统 DNS 请求方式进行修改,因此 HTTP DNS 的具体实现往往需要大量的开发工作。