一步一步测试DNS隧道

骆驼1024

已于 2024-11-08 09:38:14 修改

阅读量2.9k

点赞数 16

文章标签： frp dns隧道 iodine

于 2024-07-24 16:16:44 首次发布

本文链接：https://blog.youkuaiyun.com/imtech/article/details/140653546

版权

0、前言

在之前发过的文章里记录过关于方向代理、多重代理的内容，今天测试一下隧道。反向代理用在那些没有映射但可以出网的环境。隧道则是用在出网受限的环境，比如内部的终端、服务器仅允许ICMP、DNS流量通过的情况下。首先从复杂一点的DNS隧道开始测试，因为ICMP、SSL隧道过程节点都可控，DNS隧道要经过第三方的DNS服务器。

1、DNS解析

1.1 DNS简介

DNS解析是将域名转换为IP地址的过程，使得用户可以通过域名访问网站或服务，而不是直接使用数字IP地址。这一过程涉及到一个分布式的数据库系统，全球有多个服务器协作完成这一转换。以下是关于DNS解析的一些关键点：

定义与功能：DNS是一个分布式数据库，它将人类可读的域名映射到数字IP地址，使得用户可以通过输入容易记忆的域名来访问互联网上的资源。

工作原理：当用户尝试访问一个网站时，他们的设备首先向本地的DNS服务器发送请求。如果本地DNS服务器无法直接解答，它会向其他服务器查询，最终找到正确的IP地址并返回给用户。

1.2 DNS查询类型

DNS递归查询和迭代查询过程是域名解析的两种主要方式，它们在查询过程中扮演的角色和方式有所不同。

DNS递归查询过程：

        客户端（如浏览器）发起一个DNS查询请求，通常是通过ISP提供的递归DNS服务器进行的。
        递归DNS服务器接收请求后，会代替客户端进行后续的所有查询工作，直到找到正确的IP地址并返回给客户端。
        递归DNS服务器可能会查询根DNS服务器、顶级域名服务器（TLD）、以及权威DNS服务器，以逐级解析域名到最终的IP地址。
        如果递归DNS服务器在其缓存中找到匹配的记录，则会直接返回结果给客户端，否则会进行一系列的查询直到找到答案。

DNS迭代查询过程：

        客户端向本地DNS服务器发起查询请求。
        本地DNS服务器不直接提供答案，而是告诉客户端下一个应该查询的DNS服务器的地址。
        客户端然后向这个新的DNS服务器发送查询请求，这个过程可能会重复多次，直到找到答案或者确定没有匹配的记录。
        迭代查询过程中，客户端和DNS服务器之间的角色不变，客户端负责发起请求并跟踪下一个查询的DNS服务器地址。

总结一下：客户端发起的请求默认是递归查询，DNS服务器之间默认是迭代查询。也就是说我们向DNS提出请求后，会给到最后结果，不会再去反复查询。而域名服务器之间会反复多次查询。

下面做个测试：

1.递归查询：

使用nslookup命令查询某域名：nslookup so.com

使用Wireshark抓包，并过滤展示：

基本上一个请求一个应答，就会得到解析结果，更多的交互内容由DNS服务器完成。其他的反向查询和ipv6查询先忽略。

2.迭代查询：

使用Linux的dig命令加trace参数可以设置迭代查询：

通过抓包也可以看到反复查询的过程，感兴趣自己测试一下，可以看到世界上的13个根域名服务的ip地址。可以看到逐个会向顶级域名服务器、二级域名服务器、NS服务器请求解析的过程。

1.3 DNS解析过程

当我们访问一个网站时，域名解析的过程是这样的：Client（客户端）–> hosts文件 –> DNS Service Local Cache(自己的本地缓存) –> DNS Server(recursion递归) –> Server Cache(缓存) –> iteration(迭代) –>根 –> 顶级域名DNS –> 二级域名DNS…

在这里提一个小问题，也是前几天碰到的。我在客户现场做技术支持，发现某些域名解析不到，现场运维就看我的网卡IP配置，说没有配备用域名解析服务器。因为主要的DNS是客户自建的，备用的是用外网公用的如114.114.114.114。我说肯定不是这个原因。因为我知道主备的工作机制。

现在有个小问题，就是我们配置本机的主、备DNS服务器的工作机制是什么？也就是说什么情况下备用DNS才会使用？

这个问题答案在最后。