從安全的角度看待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 命令來顯示整個分級查詢的過程，

➜  ~ 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服務的核心，但不是我這篇文章想講述的重點，因此忽略。想了解細節的能夠本身查詢一下網絡資料，反向查詢有挺多安全知識的，我就單獨寫成一篇文章了：http://www.javashuo.com/article/p-yuujuukg-mm.html

查詢的技術細節能夠不用關心，可是常見的DNS記錄類型仍是要關心的：

A：地址記錄（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安全，今天就到這把，後續有精力在寫了.....

參考

http://www.ruanyifeng.com/blog/2016/06/dns.html
https://www.cnblogs.com/cobbliu/archive/2013/03/24/2979521.html
http://www.javashuo.com/article/p-dboenqsk-mn.html
http://www.javashuo.com/article/p-noltlvbd-mo.html