【转】DNS 报文结构和个人 DNS 解析代码实现——解决 ge

2022-01-11  本文已影响0人  lewzylu

https://segmentfault.com/a/1190000009369381转

实际应用中发现一个问题，在某些国家／ 地区的某些 ISP 提供的网络中，程序在请求 DNS 以连接一些服务器的时候，有时候会因为 ISP 的 DNS 递归查询太慢，导致设备端认为 DNS 超时了，无法获取服务器 IP。

给用户的解决方案是：请不要用 ISP 自动分配的 DNS server，改用 8.8.8.8 就解决了。

但是让用户这么配置太麻烦、也太不友好了。于是我就思考：能不能自己实现 DNS 服务，当 ISP 的 DNS 请求超时或者失败的时候，就从内部直接向 8.8.8.8 请求 DNS 信息，可以不？

如果要使用 gethostbyname() 和 getaddrinfo() 来解决这个问题的话，方案是将 /etc/resolve.conf 修改了。但这并不是正确的办法，因为这种改法一来不准确，二来会影响系统其他 DNS 请求。可行的方案是：自己构建 DNS 请求，并且自己解析获得我们需要的 IP 信息。

本文地址：https://segmentfault.com/a/1190000009369381

Reference

DNS 这样一个在网络互联中算是一个比较简单的协议，实现我如此简单的需求，居然没有哪个参考资料能够覆盖我需要的知识点……

我自己也进行了抓包，抓包的时候，建议不直接向权威的 DNS server 发送请求，而是向网关、路由器等提供 DNS 中继的服务器发，这样可以获得比下面最后一个参考资料更多的信息。

《用 TCP / IP 进行网际互联（第五版）——原理、协议与结构（第五版）》，Douglas E. Comer
《计算机网络（第5版）》，Andrew S. Tannenbaum, David J. Wetherall：男神塔能鲍姆教授！
DNS Protocol
DNS Reference Information：有各种 type 的说明
Domain Name System (DNS) Parameters：有各种参数的总集合
DNS Name Notation and Message Compression Technique
RFC-1035
对 DNS 报文的理解
DNS message解析：这篇文章也挺仔细地说明了 DNS 报文结构，图形控可以看
利用 WireShark 进行 DNS 协议分析

[图片上传失败...(image-8073ec-1641892719015)]

DNS 基本概念

简要整理一些和本文相关的点：

DNS 的本质是发明了一种层次的、基于域的命名方案，并且用一个分布式数据库系统加以实现。DNS 的主要作用是将主机名映射成 IP 地址。

DNS 解析的发起端一般是互联网 Server / Client 模型中的 client 端（以下称 client 端，指的就是发起 DNS 解析的一端），现在大部分的 C 语言 client 端都使用 getaddrinfo() 实现。以前一般用 gethostbyname() 因为一些原因不再推荐使用了，并且也只支持 IPv4。

DNS 解析中，DNS server 开放的端口应当是 53 端口。当 client 端作出请求时，server 返回的不仅仅是 IP 信息，还包含于该域名相关联的资源记录。

仅仅从一个域名 URL 中，我们不能区分这是一个域名还是某个对象（主机）名。域名的总长度应小于等于 255 个字节，域名的每一段则必须小于等于 63 字节。

[图片上传失败...(image-593ae5-1641892719015)]

DNS 报文格式

DNS 请求的格式和响应格式差不多，就不单独讲了。从 UDP 数据包的正文部分算起，DNS 报文的结构按顺序如下：

数据类型 Ethereal 里的名字 说明
uint16_t Transaction ID 标识符。下文说明
uint16_t Flags 参数。下文说明
uint16_t Questions 询问列表的数目
uint16_t Answer RRs (直接) 的回答数
uint16_t Authority RRs 认证机构数目（仅响应包里有）
uint16_t Additional RRs 附加信息数目（仅响应包里有）
variable Queries 请求数据的正文。请求包中只有这个。响应包也会附上原本的请求数据
variable Answers 响应数据的正文
variable Authortative name servers 域名管理机构数据
variable Additional records 附加信息数据

Flags

16 bits 的值，各部分按顺序如下（按顺序：位号、Ethereal 名称、说明）：

资源记录（RR）的格式

每一条 RR 的格式如下：

数据类型 Ethereal 里的名字 说明
variable Name 资源的域名——其实前文已经出现了
uint16_t Type 类型。下文说明
uint16_t Class 大多数是 0x0001，代表 IN
uint32_t Time to Live TTL 秒数
uint16_t Data length 当前 RR 剩余部分的长度
variable RR 主数据

如果是请求数据的话，那么 TTL、Data Length 和 RR 主数据都不需要

Type 的大部分值在 RFC-1035 中定义，此外的一些在其他文档定义（比如 IPv6）。我会用到的有：

[图片上传失败...(image-ebe265-1641892719014)]

域名压缩显示

这一部分直接参考的是 RFC-1035 的 “4.1.4. Message Compression”小节。

RR 中的 Name 字段，有三种表示方法（不是官方分类，而是本人自己分的）：

完整域名表示

比如表示 “www.google.com” 这样一个完整的域名，需要以下16个字节：

B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15
\3 w w w \6 g o o g l e \3 c o m \0

注意这里并不是把谷歌的 URL 使用简单的 char * 字符串复制上去，而是将每一段都分割开来。本例子中将域名分成了三段，分别是 www, google, com。每一段开头都会有一个字节，表示后面跟着的那段域名的字节长度。最后当读到 \0 的时候，表示不再有数据了（这里和 char * 的 \0 含义有一点不同，虽然形式上是一样的）

标号表示

前文我们提到，域名的每一段，最长不能超过 63 个字节，因此在表示域名段长度的这个字节的最高两位（0xC0），必然是 0。这就引申出了这里的第二种用法。

这种表示法中，相当于一个指针，指代 DNS 报文中的某一个域名段。在解析一段 RR 数据段时，需要判断域长度嘛，判断的逻辑是：

比如 0xC150，表示从 DNS 正文（UDP payload）的 offset = 0x0150 处所表示的域名。0x0150 是将 0xC150 最高两位清零得到的数字。

混合表示

这就是上面两种的混合表示。比如说，我们假设前文表示 www.google.com 的完整域名的数据段处于 DNS 报文偏移 0x20 处，那么有以下几种可能的用法：

[图片上传失败...(image-7833d7-1641892719014)]

分析工具

除了 Ethereal 之外，推荐的分析工具有：

[图片上传失败...(image-3ab20b-1641892719014)]

代码实现

代码实现在我用来研究 epoll() 的分支中，GitHub 工程在此，许可证为 LGPL。
实现逻辑上其实还是挺简单的，照着上面提到的原理实现就好了。大部分的代码和本文无关，只需要看里面的 AMCDns.c / h 文件即可。

我的这些代码可以完全代替阻塞的 getaddrinfo() 函数，甚至也可以集成到异步 I/O 库中。使用流程如下：

  1. 调用 socket() 创建一个 UDP 套接字并 bind()
  2. 调用 AMCDns_GetDefaultServer() 获取系统默认配置的 DNS 服务器
  3. 如果不使用系统默认的 DNS 服务器，则需要使用 struct addrinfo 类型来指定。
  4. 调用 AMCDns_SendRequest() 请求指定域名的 IP 信息
  5. 调用 AMCDns_RecvAndResolve() 获取摘要的或完整的响应。
  6. 调用 AMCDns_FreeResult() 清除 DNS 响应数据以避免内存泄露
  7. close() 掉 socket
上一篇下一篇

猜你喜欢

热点阅读