闲来无事，水文一篇。
Domain Name System，域名系统。百度百科 。通俗来说就是将域名转换成IP地址，DNS通信通过UDP、TCP 53端口。例如我们用host命令来查询one.one.one.one对应的IP地址
$ host one.one.one.one
one.one.one.one has address 1.0.0.1
one.one.one.one has address 1.1.1.1
one.one.one.one has IPv6 address 2606:4700:4700::1111
one.one.one.one has IPv6 address 2606:4700:4700::1001
DNS根服务器（根域名服务器）有13组。分别对应的域名是 字母a-字母m.root-servers.net。这些域名的IP地址都写到了操作系统的底层。以便我们可以直接使用这些服务器来查询DNS记录。我们可以也可以使用dig命令来复现迭代解析的过程。
# dig 33.al +trace
; <<>> DiG 9.16.1-Ubuntu <<>> 33.al +trace
;; global options: +cmd
. 2104 IN NS k.root-servers.net.
. 2104 IN NS a.root-servers.net.
. 2104 IN NS f.root-servers.net.
. 2104 IN NS l.root-servers.net.
. 2104 IN NS d.root-servers.net.
. 2104 IN NS e.root-servers.net.
. 2104 IN NS b.root-servers.net.
. 2104 IN NS h.root-servers.net.
. 2104 IN NS c.root-servers.net.
. 2104 IN NS i.root-servers.net.
. 2104 IN NS j.root-servers.net.
. 2104 IN NS m.root-servers.net.
. 2104 IN NS g.root-servers.net.
;; Received 228 bytes from 223.5.5.5#53(223.5.5.5) in 10 ms
al. 172800 IN NS rip.psg.com.
al. 172800 IN NS ns1.nic.al.
al. 172800 IN NS munnari.oz.au.
al. 172800 IN NS nsx.nic.al.
al. 86400 IN NSEC alfaromeo. NS RRSIG NSEC
al. 86400 IN RRSIG NSEC 8 1 86400 20201016050000 20201003040000 26116 . BqznHaGD1zAX4wIS9TozNCw6dlj03gzFV03Ta3p+rXlrSoTd7iWPe+Sm vvCp+ss5tacWjTA6LpyFbjzapk1n9u52wL/Nt3+ktuz3nUPRA8f57yR+ 4tQsmrBQEdqkA+KNuQsZ5v7tjsFdyZwy7QeXjadbVAinjGIARdDWiTr7 BgjqR0pRb0QLmZ4BULyAEoQP0muQ2io8NsZiI7GgCzgT1yA5n4HjchV+ CZHNinqQJ3uppZy05Vw5MFTJAag1uhe3fK6Rc8IyVqFzon3WAf2p8AQV 5cKG5crnt/HtZjjPh8W9CbfNrRO0bsCZ4EibUSK6iOIMqlCP4lHLkQSe vJ9wjQ==
;; Received 648 bytes from 192.112.36.4#53(g.root-servers.net) in 341 ms
33.al. 18000 IN NS uma.ns.cloudflare.com.
33.al. 18000 IN NS darl.ns.cloudflare.com.
;; Received 116 bytes from 194.0.11.108#53(nsx.nic.al) in 352 ms
33.al. 300 IN A 143.92.43.43
;; Received 50 bytes from 172.64.32.146#53(uma.ns.cloudflare.com) in 320 ms
先向根域名服务器查询所有
.al域名后缀的解析归谁管理。然后根域名服务器返回了一堆结果。又继续向返回的结果中的nsx.nic.al查询33.al的域名解析归谁管理。而后继续向uma.ns.cloudflare.com查询33.al到底解析到了哪里。最后终于得到了IP地址。
这一过程未免太过繁琐。所以一般使用中我们用到的是另一种解析方式。即递归解析。运营商或者其他组织会提供公共的DNS解析服务器（例如阿里云的223.5.5.5）。我们直接向它查询解析33.al的解析记录,如果它本地也没有缓存的话，就会执行迭代解析的过程然后将结果缓存到自己的服务器上，下次别人再查询的话就可以直接返回相关记录，加快DNS请求的等待过程。
可以从DNS中得到什么？DNS会泄露什么？
既然是从DNS方式入手。目前笔者可想到泄露有两处。
泄露我们目前的地域信息
一般客户端使用的都是运营商提供DNS或者223.5.5.5这种的公共服务。运营商肯定是和我们所在的地区紧密相关的。公共服务为了加快解析速度，也会使用
IP任播的方式在多个地域设置节点，查询请求会通过速度最优的方式来进行，也就无法避免和地域之间的关系。情景
某人注册了域名 eyi.com，且使用自建的DNS服务器224.6.6.6。且完整保存相关DNS请求记录。这样就可以从DNS请求的方式 对访客大致地域进行统计。
情景
如果某访客使用的VPN并没有涵盖DNS协议。DNS请求还是通过本机的DNS发送出去。DNS请求就可以泄露访客的真实地域信息。
相关实现：
https://browserleaks.com/ip 实时显示当前访客的DNS。
泄露我们查询的域名
想象一下。如果某公司拥有全网所有的DNS请求数据。先通过域名对访客的网站进行分类。然后依据网站的种类和访客的DNS请求，再对访客进行筛选。比如你经常上LOL、STEAM。你的标签就
网游+1。想象一下，这些数据可以用来。。。当然这也是一把双刃剑，例如当年的 iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com 【WannaCry所使用的开关域名】。DNS服务商也可以依据该域名的解析情况来对病毒的传播情况进行了解。也可以通过DNS解析的方式直接切断病毒的传播（不仅包括WannaCry），目前还没有大型的DNS服务商默认使用这一手段。但是有很多DNS服务商推出了所谓的“安全DNS”来作为增值服务。
DNS隧道：使用DNS进行隐蔽通信
鉴于DNS的特殊性，很多内网即使在断网的情况下还是会允许DNS协议的放行。不出网的情况下，常规的远程控制、SHELL反弹等方式均已失效。但是DNS隧道还是可以尝试。仅需一个自建的DNS服务器即可进行正常通信。性价比较高。例如:iodine,chashell,dnscat,reverse_dns_shell,dns2tcp,cobalt strike等公开工具均可实现DNS隧道的通信。
还有很火的DNSlog，大量使用在批量漏洞验证阶段处。通过执行系统命令或者发起网络请求的payload进行DNS解析,解析的域名使用自建的DNS服务器。一旦发现有相关的DNS请求产生，即代表存在某漏洞。目前常见的是shiro反序列化、fastjson反序列化、等漏洞的利用。
以笔者目前的理解。检测DNS隧道的方式还不完善，即使是人工也很难在大量的DNS请求记录中发现DNS隧道的痕迹。（排除例如dnscat的强特征,dnslog已知平台收集）。目前针对内网只有白名单的方式来阻止DNS隧道传递信息，或者干脆直接禁用掉DNS。