从安全的角度看待DNS

以前对DNS(Domain Name System)认识就大概的知道是一个提供域名解析服务，作为互联网的基础设施，任何一个IT人员都会或多或少都接触到DNS，随着我最近的接触不断提高，我发现DNS还是有很多细节技术需要认识和把握的，本文以一个中型互联网企业搭建域DNS服务器架构为基础，从安全的角度看待DNS进行描述，都是一些经验之谈，希望读者能有所收获。

DNS协议

DNS通过开放53端口，通过该端口来监听请求并提供响应的服务，DNS 监听 TCP 和 UDP 都是 53 端口。如果攻击人员在扫描主机端口的时候发现一台主机开放了53端口，那么就可以判断这是一台DNS服务器，并且对外了。对外开放53端口，也就意味着运行外部对这台DNS服务器进行安全扫描，如何进行安全扫描，DNS会有哪些安全问题，后面会说。

出于性能的考虑，DNS查询请求用UDP协议交互并且每个请求的大小小于512字节，但是如果返回的请求大小大于512字节，交互双方会协商使用TCP协议。

DNS查询

说完DNS的端口，那就接着说DNS的服务，DNS提供出来的就是域名解析服务（将域名转换为IP地址的过程），这个服务是怎么实现域名解析服务的？我说一下大概查询过程（如下两张图）

 

 

假设你想访问 sspai.com 这个网站，那么就如走这个流程

• 先问 客户端（本地主机）DNS服务器
• 再问 局部（局域网）DNS域服务器
• 再去问 根域名
• 最后问 顶级域名服务器

如果使用类linux系统，可以使用 dig 命令来显示整个分级查询的过程，

Copy➜  ~ dig +trace sspai.com

; <<>> DiG 9.10.6 <<>> +trace sspai.com
;; global options: +cmd


# 第一段列出根域名.的所有NS记录，即所有根域名服务器。
.            3600    IN    NS    d.root-servers.net.
.            3600    IN    NS    k.root-servers.net.
.            3600    IN    NS    j.root-servers.net.
.            3600    IN    NS    a.root-servers.net.
.            3600    IN    NS    b.root-servers.net.
.            3600    IN    NS    e.root-servers.net.
.            3600    IN    NS    f.root-servers.net.
.            3600    IN    NS    h.root-servers.net.
.            3600    IN    NS    c.root-servers.net.
.            3600    IN    NS    i.root-servers.net.
.            3600    IN    NS    g.root-servers.net.
.            3600    IN    NS    l.root-servers.net.
.            3600    IN    NS    m.root-servers.net.
;; Received 472 bytes from 10.249.150.1#53(10.249.150.1) in 1 ms


# 接着询问sspai.com的顶级域 com.的NS记录
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            86400    IN    DS    30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.            86400    IN    RRSIG    DS 8 1 86400 20200801170000 20200719160000 46594 . nl6GGtQwgNAf1YLcWFFcQyXZ1BE/E5dhOVVBIxTCl0QNtvt9sb+btQIM NOVpc6JovoxxfXvDxotRmCqVe9BJunaZvCqMGySy8JdFTcSo1kdVKXvU nI+b3mad5ROgvP2GaUZelhRIn7++FIQAjSUl40H/jdaQP2fxXDH1PQ4B oBhQwnlDo/rn3AJxhH+P2hx/23fadNwsmh/WY9truU1Gv4cf+uwAPkE9 QFSKDcDF7VgTF1bHN9A9nuURQXIjGQkZAGUHaR9bIrKtgYDa3szrmdOJ GejllYy4VyKoBxwZLkV+W7gt+ODYXxAz42UFk5VOGF560wfCIM11FSYR +XPqPg==
;; Received 1169 bytes from 192.36.148.17#53(i.root-servers.net) in 65 ms


# 询问sspai.com的次级域名 NS记录
sspai.com.        172800    IN    NS    dns17.hichina.com.
sspai.com.        172800    IN    NS    dns18.hichina.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A  NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200724044108 20200717033108 24966 com. Tf4OQOpeShS1V8R5W7+YWbLa+iIn/wJf3iDfMsHf4P7TJ1ZBm+1EC4FB bdE2Xcyi9wFIetecgTseEQGLYEKdwUBx6mqGmR3nHMaRDl+4Sm+hBufD UUR+2sGFNM/KMWC5zgm7nLc4wHBSrsq8T36nache8cXBhEWSEvR+MIGw o1fJdUNWhihU/maM05P4wrigqDw5igwIkDZZ1O3Fz5uwnQ==
M34OU778JRD89U2DUUTAAI48T6FEI7CV.com. 86400 IN NSEC3 1 1 0 - M34P2GDRCOK7PL50LT2A785I7P76KSGS  NS DS RRSIG
M34OU778JRD89U2DUUTAAI48T6FEI7CV.com. 86400 IN RRSIG NSEC3 8 2 86400 20200725051418 20200718040418 24966 com. Fis/2uVliOd9QYjFtzH0SVeSU4lAtekdPXOlqU5Zp+IxDXOovSM31wmL YD9zQRdfecDoiurSZi/yZceE2HxgWyWDc1epW7gTQYGOr99s7dxA08dm +gZZIExIIYNpc1MzSqktmLQuOg9yyUQwyf1YWCrQF8d+e3/fdPxFBunf j2psiF3BKzhPt5tlzfx98Gu8pckCBk9pV3xFXCAv5Vx0/A==
;; Received 947 bytes from 192.41.162.30#53(l.gtld-servers.net) in 177 ms


## 查询到有一条A记录，通过这个IP(119.23.141.248) 地址就可以访问到这个网站
sspai.com.        600    IN    A    119.23.141.248
;; Received 54 bytes from 140.205.41.28#53(dns18.hichina.com) in 31 ms

而具体实现这个查询过程的技术有

• 递归查询
• 迭代查询
• 反向查询

这里的每种查询技术都不简单，迭代、递归查询也是实现DNS服务的核心，但不是我这篇文章想讲述的重点，所以忽略。想了解细节的可以自己查询一下网络资料，反向查询有挺多安全知识的，我就单独写成一篇文章了：https://www.cnblogs.com/mysticbinary/p/13344930.html

查询的技术细节可以不用关心，但是常见的DNS记录类型还是要关心的：

CopyA：地址记录（Address），返回域名指向的IP地址。
AAAA ：A 记录处理 IPV4，AAAA 处理 IPV6。

SOA ：起始授权机构记录，SOA 备注说明了众多 NS（name server）记录中谁是主名称服务器，不参与功能，但是不能缺少。
NS：域名服务器记录（Name Server），返回保存下一级域名信息的服务器地址。该记录只能设置为域名，不能设置为IP地址。

MX：邮件记录（Mail eXchange），返回接收电子邮件的服务器地址。

CNAME：规范名称记录（Canonical Name），返回另一个域名，即当前查询的域名是另一个域名的跳转（类似302跳转）。

PTR：逆向查询记录（Pointer Record），只用于从IP地址查询域名。

答应我！下次你在看到A、AAAA、SOA、NS、MX、CNAME、PTR一定要一秒之内想出他们是干嘛的。因为太重要了。答应我！下次你在看到A、AAAA、SOA、NS、MX、CNAME、PTR一定要一秒之内想出他们是干嘛的。因为太重要了。答应我！下次你在看到A、AAAA、SOA、NS、MX、CNAME、PTR一定要一秒之内想出他们是干嘛的。因为太重要了。

从安全的角度上看，为了保证服务的安全可靠，至少应该有两条NS记录，而A记录和MX记录也可以有多条，这样就提供了服务的冗余性，防止出现单点失败。

域维护

因为DNS服务就是一个类似分布式的服务，分布式就是分散的，如何保证各个分散的机器能及时的同步消息呢？在主域名服务器和从域名服务器之间维护同一个zone文件。可以简单的理解为，DNS设定一个协议来在主域名服务器和从域名服务器之间维护同一个zone文件。主要有以下两种同步的手段有：

• 全量传输 AXFR (full zone transfer)
  就是设定一个固定时间（比如2分钟一次），就同步一次zone文件
• 增量传输 IXFR (incremental zone transfer)
  传递非常大的zone文件是非常耗资源的（时间、带宽等），尤其是只有zone中的一个记录改变的时候，没有必要传递整个zone文件，增量传输是允许主域名服务器和从域名服务器之间只传输那些改变的记录。

ZONE文件是DNS上保存域名配置的文件，一个域名对应一个ZONE文件。

如果你的企业局域网只有一台DNS服务器，那么就不需要AXFR、IXFR

 

如果你的企业局域网有多台DNS服务器，那么就需要AXFR、IXFR

 

做DNS监控，就会用到ES技术，通过记录，你会发现你记录的DNS服务器clientIp为127.0.0.1，并且在固定周期就会传输AXFR类型的Domain。

 

DNS安全

DNS本身的DNS服务漏洞、区域转发配置错误、找真实IP绕过WAF等，都是常见的DNS安全，今天就到这吧

转自https://www.toutiao.com/i6852520470315532814/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1595811935&app=news_article&utm_source=weixin&utm_medium=toutiao_android&use_new_style=1&req_id=20200727090535010016041054098AB026&group_id=6852520470315532814