DNS的核心工作就是將域名翻譯成計算機IP地址, 它是基於UDP協議實現的，本文將具體闡述DNS相關的概念，解析，調度原理（負載均衡和區域調度）等DNS相關的所有知識點。 @pdai
DNS簡介
域名系統並不像電話號碼通訊錄那麼簡單，通訊錄主要是單個個體在使用，同一個名字出現在不同個體的通訊錄裏並不會出現問題，但域名是羣體中所有人都在用的，必須要保持唯一性。爲了達到唯一性的目的，因特網在命名的時候採用了層次結構的命名方法。每一個域名（本文只討論英文域名）都是一個標號序列（labels），用字母（A-Z，a-z，大小寫等價）、數字（0-9）和連接符（-）組成，標號序列總長度不能超過255個字符，它由點號分割成一個個的標號（label），每個標號應該在63個字符之內，每個標號都可以看成一個層次的域名。級別最低的域名寫在左邊，級別最高的域名寫在右邊。域名服務主要是基於UDP實現的，服務器的端口號爲53。
域名層級結構
注意：最開始的域名最後都是帶了點號的，比如
www.kernel.org.，最後面的點號表示根域名服務器，後來發現所有的網址都要加上最後的點，就簡化了寫法，乾脆所有的都不加即www.kernel.org，但是你在網址後面加上點號也是可以正常解析的。
域名服務器
有域名結構還不行，還需要有一個東西去解析域名，手機通訊錄是由通訊錄軟件解析的，域名需要由遍及全世界的域名服務器去解析，域名服務器實際上就是裝有域名系統的主機。由高向低進行層次劃分，可分爲以下幾大類：
- 根域名服務器：最高層次的域名服務器，也是最重要的域名服務器，本地域名服務器如果解析不了域名就會向根域名服務器求助。全球共有13個不同IP地址的根域名服務器，它們的名稱用一個英文字母命名，從a一直到m。這些服務器由各種組織控制，並由 ICANN（互聯網名稱和數字地址分配公司）授權，由於每分鐘都要解析的名稱數量多得令人難以置信，所以實際上每個根服務器都有鏡像服務器，每個根服務器與它的鏡像服務器共享同一個 IP 地址，中國大陸地區內只有6組根服務器鏡像（F，I（3臺），J，L）。當你對某個根服務器發出請求時，請求會被路由到該根服務器離你最近的鏡像服務器。所有的根域名服務器都知道所有的頂級域名服務器的域名和地址，如果向根服務器發出對 “pdai.tech” 的請求，則根服務器是不能在它的記錄文件中找到與 “pdai.tech” 匹配的記錄。但是它會找到 "tech" 的頂級域名記錄，並把負責 "tech" 地址的頂級域名服務器的地址發回給請求者。
- 頂級域名服務器：負責管理在該頂級域名服務器下注冊的二級域名。當根域名服務器告訴查詢者頂級域名服務器地址時，查詢者緊接着就會到頂級域名服務器進行查詢。比如還是查詢"pdai.tech"，根域名服務器已經告訴了查詢者"tech"頂級域名服務器的地址，"tech"頂級域名服務器會找到 “pdai.tech”的域名服務器的記錄，域名服務器檢查其區域文件，並發現它有與 “pdai.tech” 相關聯的區域文件。在此文件的內部，有該主機的記錄。此記錄說明此主機所在的 IP 地址，並向請求者返回最終答案。
- 權限域名服務器：負責一個區的域名解析工作
- 本地域名服務器：當一個主機發出DNS查詢請求的時候，這個查詢請求首先就是發給本地域名服務器的。
DNS 解析流程
網上找了個比較好的例子
.com.fi國際金融域名DNS解析的步驟一共分爲9步，如果每次解析都要走完9個步驟，大家瀏覽網站的速度也不會那麼快，現在之所以能保持這麼快的訪問速度，其實一般的解析都是跑完第4步就可以了。除非一個地區完全是第一次訪問（在都沒有緩存的情況下）纔會走完9個步驟，這個情況很少。
- 1、本地客戶機提出域名解析請求，查找本地HOST文件後將該請求發送給本地的域名服務器。
- 2、將請求發送給本地的域名服務器。
- 3、當本地的域名服務器收到請求後，就先查詢本地的緩存。
- 4、如果有該紀錄項，則本地的域名服務器就直接把查詢的結果返回瀏覽器。
- 5、如果本地DNS緩存中沒有該紀錄，則本地域名服務器就直接把請求發給根域名服務器。
- 6、然後根域名服務器再返回給本地域名服務器一個所查詢域（根的子域）的主域名服務器的地址。
- 7、本地服務器再向上一步返回的域名服務器發送請求，然後接受請求的服務器查詢自己的緩存，如果沒有該紀錄，則返回相關的下級的域名服務器的地址。
- 8、重複第7步，直到找到正確的紀錄。
- 9、本地域名服務器把返回的結果保存到緩存，以備下一次使用，同時還將結果返回給客戶機。
注意事項：
遞歸查詢：在該模式下DNS服務器接收到客戶機請求，必須使用一個準確的查詢結果回覆客戶機。如果DNS服務器本地沒有存儲查詢DNS信息，那麼該服務器會詢問其他服務器，並將返回的查詢結果提交給客戶機。
迭代查詢：DNS所在服務器若沒有可以響應的結果，會向客戶機提供其他能夠解析查詢請求的DNS服務器地址，當客戶機發送查詢請求時，DNS服務器並不直接回複查詢結果，而是告訴客戶機另一臺DNS服務器地址，客戶機再向這臺DNS服務器提交請求，依次循環直到返回查詢的結果爲止。
爲什麼DNS通常基於UDP
使用基於UDP的DNS協議只要一個請求、一個應答就好了
而使用基於TCP的DNS協議要三次握手、發送數據以及應答、四次揮手
明顯基於TCP協議的DNS更浪費網絡資源！
當然以上只是從數據包的數量以及佔有網絡資源的層面來進行的分析，那數據一致性層面呢？
DNS數據包不是那種大數據包，所以使用UDP不需要考慮分包，如果丟包那麼就是全部丟包，如果收到了數據，那就是收到了全部數據！所以只需要考慮丟包的情況，那就算是丟包了，重新請求一次就好了。而且DNS的報文允許填入序號字段，對於請求報文和其對應的應答報文，這個字段是相同的，通過它可以區分DNS應答是對應的哪個請求
DNS通常是基於UDP的，但當數據長度大於512字節的時候，爲了保證傳輸質量，就會使用基於TCP的實現方式
DNS 查詢
dig 查詢
用
dig可以查看整個過程，看下下面的返回就能理解的
- dig www.sina.com
pdaiMbp:/ pdai$ dig www.sina.com
; <<>> DiG 9.10.6 <<>> www.sina.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15304
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.sina.com. IN A
;; ANSWER SECTION:
www.sina.com. 32 IN CNAME us.sina.com.cn.
us.sina.com.cn. 32 IN CNAME spool.grid.sinaedge.com.
spool.grid.sinaedge.com. 32 IN A 115.238.190.240
;; Query time: 20 msec
;; SERVER: 192.168.3.1#53(192.168.3.1)
;; WHEN: Fri Jan 31 14:53:39 CST 2020
;; MSG SIZE rcvd: 108
- dig +trace www.sina.com // 分級查詢
pdaiMbp:/ pdai$ dig +trace www.sina.com
; <<>> DiG 9.10.6 <<>> +trace www.sina.com
;; global options: +cmd
. 52722 IN NS f.root-servers.net.
. 52722 IN NS k.root-servers.net.
. 52722 IN NS m.root-servers.net.
. 52722 IN NS l.root-servers.net.
. 52722 IN NS d.root-servers.net.
. 52722 IN NS i.root-servers.net.
. 52722 IN NS c.root-servers.net.
. 52722 IN NS e.root-servers.net.
. 52722 IN NS a.root-servers.net.
. 52722 IN NS g.root-servers.net.
. 52722 IN NS b.root-servers.net.
. 52722 IN NS h.root-servers.net.
. 52722 IN NS j.root-servers.net.
;; Received 228 bytes from 192.168.3.1#53(192.168.3.1) in 3 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.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 20200213050000 20200131040000 33853 . zMeZpKg/LGzpVjlBUJRfkmk8tSvZW+L0UFHnzSn8agztJ8sMGU+knBLW 5LLoPoh6iG7exLV5wVIJZVh+0ISk3AG85VJXZ3HSTWcHZfjMOYI7JXpe pv/5JqT9Eai0ScEJAowDa1qctGOE/LHdNwr30VF8U0LoZL0iXVN3KQ4k iKnl0S0hB41KH+BHFcNpWqxKHRK2piMZRNe8+8Nu9I4GilfW/D90e69p SgG7puU3J3srarhccj0OS5WcLi6nsMf/2k0C6rQMe+WD7aOVZXoLts93 /thoNSWIprseKrYze2STnuG+T/VxzZRJ3fjoZARGHtDf3gTibHC2syXL xaXz5w==
;; Received 1172 bytes from 198.97.190.53#53(h.root-servers.net) in 54 ms
sina.com. 172800 IN NS ns1.sina.com.cn.
sina.com. 172800 IN NS ns2.sina.com.cn.
sina.com. 172800 IN NS ns3.sina.com.cn.
sina.com. 172800 IN NS ns1.sina.com.
sina.com. 172800 IN NS ns2.sina.com.
sina.com. 172800 IN NS ns4.sina.com.
sina.com. 172800 IN NS ns3.sina.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200207054811 20200131043811 56311 com. N15f7ia8A0pd2A5iWM/8t+T6gs8mQJaOWe/aj3bs4cWxpG7WmCaquZp7 6gfbfotFmss+DuBm9MAd6bwe2fm9m60FQgROWGOZwGRrvZqawy/5eDeV sLIJqhnwM0lT1PuDgNe2SFYsV506melwC4cEtR8M6gkX3nwYMCf6Frus anO+4Lufi229N5Y00N4x9vrlO3zsGBR1yg2xBki9Ni379A==
TGAG8VMC6NS5VVK68CIGRJ6Q414N2KB2.com. 86400 IN NSEC3 1 1 0 - TGAGRAEN3DVBS761O1PSQ1TU0407EVHO NS DS RRSIG
TGAG8VMC6NS5VVK68CIGRJ6Q414N2KB2.com. 86400 IN RRSIG NSEC3 8 2 86400 20200206061700 20200130050700 56311 com. TMrk1/56Wa+isS5Y6OFQz9OZWMAAbt2TOEzaBp1Uuj9z1Eg4uio92+ff sWRB6vACYSBAJJLy4NPJfqxYpue39hvaDgFRYAZreDuCC0x+p9yi7yQ8 JaN2mS7W8Mbv0iEV0AUyzZGyhYq83DA58slNSGRhZfcvLYBAETURyH0X bJp+Hgq0bqXOqGyi/lAAv8/2mr+tiramb/pNst1MBBPaig==
;; Received 791 bytes from 192.48.79.30#53(j.gtld-servers.net) in 215 ms
www.sina.com. 60 IN CNAME us.sina.com.cn.
us.sina.com.cn. 60 IN CNAME spool.grid.sinaedge.com.
;; Received 103 bytes from 180.149.138.199#53(ns2.sina.com.cn) in 30 ms
域名與IP之間的對應關係，稱爲"記錄"（record）。根據使用場景，"記錄"可以分成不同的類型（type），前面已經看到了有A記錄和NS記錄。
常見的DNS記錄類型如下。
- A：地址記錄（Address），返回域名指向的IP地址。
- NS：域名服務器記錄（Name Server），返回保存下一級域名信息的服務器地址。該記錄只能設置爲域名，不能設置爲IP地址。
- MX：郵件記錄（Mail eXchange），返回接收電子郵件的服務器地址。
- CNAME：規範名稱記錄（Canonical Name），返回另一個域名，即當前查詢的域名是另一個域名的跳轉，詳見下文。
- PTR：逆向查詢記錄（Pointer Record），只用於從IP地址查詢域名，詳見下文。
一般來說，爲了服務的安全可靠，至少應該有兩條NS記錄，而A記錄和MX記錄也可以有多條，這樣就提供了服務的冗餘性，防止出現單點失敗。
CNAME記錄主要用於域名的內部跳轉，爲服務器配置提供靈活性，用戶感知不到。
host查詢
pdaiMbp:/ pdai$ host www.sina.com
www.sina.com is an alias for us.sina.com.cn.
us.sina.com.cn is an alias for spool.grid.sinaedge.com.
spool.grid.sinaedge.com has address 115.238.190.240
spool.grid.sinaedge.com has IPv6 address 240e:f7:a000:221::75:71
nslookup查詢
pdaiMbp:/ pdai$ nslookup
> www.sina.com
Server: 192.168.3.1
Address: 192.168.3.1#53
Non-authoritative answer:
www.sina.com canonical name = us.sina.com.cn.
us.sina.com.cn canonical name = spool.grid.sinaedge.com.
Name: spool.grid.sinaedge.com
Address: 115.238.190.240
whois查詢
pdaiMbp:/ pdai$ whois www.sina.com
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
refer: whois.verisign-grs.com
domain: COM
organisation: VeriSign Global Registry Services
address: 12061 Bluemont Way
address: Reston Virginia 20190
address: United States
contact: administrative
name: Registry Customer Service
organisation: VeriSign Global Registry Services
address: 12061 Bluemont Way
address: Reston Virginia 20190
address: United States
phone: +1 703 925-6999
fax-no: +1 703 948 3978
e-mail: [email protected]
contact: technical
name: Registry Customer Service
organisation: VeriSign Global Registry Services
address: 12061 Bluemont Way
address: Reston Virginia 20190
address: United States
phone: +1 703 925-6999
fax-no: +1 703 948 3978
e-mail: [email protected]
nserver: A.GTLD-SERVERS.NET 192.5.6.30 2001:503:a83e:0:0:0:2:30
nserver: B.GTLD-SERVERS.NET 192.33.14.30 2001:503:231d:0:0:0:2:30
nserver: C.GTLD-SERVERS.NET 192.26.92.30 2001:503:83eb:0:0:0:0:30
nserver: D.GTLD-SERVERS.NET 192.31.80.30 2001:500:856e:0:0:0:0:30
nserver: E.GTLD-SERVERS.NET 192.12.94.30 2001:502:1ca1:0:0:0:0:30
nserver: F.GTLD-SERVERS.NET 192.35.51.30 2001:503:d414:0:0:0:0:30
nserver: G.GTLD-SERVERS.NET 192.42.93.30 2001:503:eea3:0:0:0:0:30
nserver: H.GTLD-SERVERS.NET 192.54.112.30 2001:502:8cc:0:0:0:0:30
nserver: I.GTLD-SERVERS.NET 192.43.172.30 2001:503:39c1:0:0:0:0:30
nserver: J.GTLD-SERVERS.NET 192.48.79.30 2001:502:7094:0:0:0:0:30
nserver: K.GTLD-SERVERS.NET 192.52.178.30 2001:503:d2d:0:0:0:0:30
nserver: L.GTLD-SERVERS.NET 192.41.162.30 2001:500:d937:0:0:0:0:30
nserver: M.GTLD-SERVERS.NET 192.55.83.30 2001:501:b1f9:0:0:0:0:30
ds-rdata: 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CFC41A5766
whois: whois.verisign-grs.com
status: ACTIVE
remarks: Registration information: http://www.verisigninc.com
created: 1985-01-01
changed: 2017-10-05
source: IANA
No match for domain "WWW.SINA.COM".
>>> Last update of whois database: 2020-01-31T07:03:29Z <<<
在線工具查詢
https://www.nslookuptool.com/chs/
DNS 調度原理
本節轉自：【網易MC】DNS 調度原理解析
現在，大部分應用和業務都採用域名作爲服務的入口，因此用 DNS 來負載均衡和區域調度是非常普遍的做法，網易雲也有着一套基於 DNS 的調度系統。某些用戶在進行直播推流時用的並不是網易雲的直播 SDK，而是一些第三方的推流軟件，如obs，這樣就不能使用我們的 GSLB 全局調度服務器來調度。對於這些用戶，我們使用 DNS 調度的方式，對不同地域的請求返回不同解析結果，將請求調度到離用戶最近的服務器節點，從而減少延遲訪問。
咋一看，DNS 調度這麼簡單方便，那爲什麼不讓所有的用戶都走 DNS 調度呢？想知道原因？來，我們繼續講。
地理位置調度不準確
在 DNS 解析過程中，與權威服務器通信的只有 DNS 緩存服務器，所以權威服務器只能根據 DNS 緩存服務器的IP來進行調度。因此 DNS 調度有一個前提：假定用戶使用的緩存DNS與用戶本身在同個網絡內，即至少在同一個 AS(自治域)內，在該前提下，DNS 的解析纔是準確的。通常情況下，用戶使用 ISP 提供的本地緩存(簡稱 local DNS)，local DNS 一般與用戶在同個網絡內，這時候 DNS 調度是有效的。
但近些年，不少互聯網廠商推廣基於 BGP Anycast 的公共 DNS (Public DNS)，而這些Anycaset IP 的節點一般是遠少於各個ISP的節點，例如可能廣州電信用戶使用了某公共 DNS，但該公共 DNS 裏用戶最近的是上海電信節點，甚至更極端的如 Google DNS 8.8.8.8，在中國大陸沒有節點(最近的是臺灣)。而不幸的是國內有不少用戶使用了 Google DNS，這其實降低了他們的網絡訪問體驗。總的來說，使用公共 DNS，實際上破壞了上文的前提，導致 DNS 區域調度失效，用戶以爲得到了更快更安全的 DNS 解析，但實際得到了錯誤的解析，增加了網絡訪問延遲。
傳統 DNS 協議的區域調度過程示例如下圖，假定某業務以 foo.163.com 對外提供服務，在北京和東京各有一個節點，業務期望國內大陸的用戶訪問北京節點，而非大陸用戶則訪問東京節點。因爲權威是根據 DNS 緩存來決定返回的結果，所以當用戶使用不用的 DNS 緩存時，可能會解析到不同的結果。
2011 年，Google 爲首的幾家公司在提出了一個 DNS 的擴展方案 edns-client-subnet (以下簡稱 ECS)，該擴展方案的核心思想是通過在 DNS 請求報文里加入原始請求的 IP(即 client 的 IP)，使得權威能根據該信息返回正確的結果。目前，該方案仍處於草案階段。該方案很好地解決了上述提到的 remote DNS 導致解析不準確的問題，但也帶了一些問題：
- 至少需要 cache 和權威都支持，才能完成完整的 ECS 解析
- ECS 給 cache 增加了很大的緩存壓力，因爲理論上可能需要爲每個IP段分配空間去緩存解析結果
規則變更生效時間不確定
當緩存服務器向權威服務器查詢得到記錄之後，會將其緩存起來，在緩存有效期內，如果收到相同記錄的查詢，緩存服務器會直接返回給客戶端，而不需要再次向權威查詢，當有效期過後，緩存則是需要再次發起查詢。這個緩存有效期即是 TTL。
雖然 DNS 的緩存機制在大多數情況下縮短了客戶端的記錄解析時間，但緩存也意味着生效同步的延遲。當權威服務器的記錄變更時，需要等待一段時間才能讓所有客戶端能解析到新的結果，因爲很可能緩存服務器還緩存着舊的記錄。
我們將權威的記錄變更到全網生效這個過程稱爲 propagation，它的時間是不確定的，理論上的最大值即是 TTL 的值，對於記錄變更或刪除，這個時間是記錄原本的 TTL，對於記錄新增則是域的 nTTL 值。
如果一個域名記錄原本的 TTL 是 18000，可以認爲，變更該記錄理論上需要等待 5 個小時才能保證記錄能生效到全網。假設該域名的業務方希望縮短切換的時間，正確的做法是，至少提前5個小時修改記錄，僅改小 TTL，例如改爲5分鐘，等待該變更同步到全網之後，再進行修改指向的操作，確認無誤再將 TTL 修改爲原本的值。
雖然 DNS 協議標準裏建議緩存服務器應該記住或者縮短 TTL 的值，但實際上，有一些DNS緩存會修改權威服務器的 TTL，將其變大，這在國內幾大運營商中是很常見的。例如，某域記錄的 TTL 值實際上設置爲 60，但在運營商的 DNS 緩存上，卻變成 600 或者更大的值，甚至還有一些 DNS 緩存是不遵循 TTL 機制。這些都會影響域名的實際生效時間。
高可用
爲避免受 DNS 緩存的影響，需要保證 DNS 中 A 記錄的 IP 節點高可用性。對此，網易雲DNS 調度系統採用的方案是在同一區域的多臺直播服務器節點之間做負載均衡，對外只暴露一個虛 IP，這樣，即使某臺服務器宕機，負載均衡能迅速感知到，排除故障節點，而對 DNS 而言，因爲虛 IP 不變而不受影響。
DNS 安全相關
本章節部分內容參考自： OneAPM blog
犯罪分子會抓住任何互聯網服務或協議的漏洞發動攻擊，這當然也包括域名系統（ DNS ）。他們會註冊一次性域名用於垃圾郵件活動和殭屍網絡管理，還會盜用域名進行釣魚和惡意軟件下載。他們會注入惡意查詢代碼以利用域名服務器的漏洞或擾亂域名解析過程。他們會注入僞造的響應污染解析器緩存或強化 DDOS 攻擊。他們甚至將 DNS 用作數據滲漏或惡意軟件更新的隱蔽通道。
你可能沒辦法瞭解每一個新的 DNS 漏洞攻擊，但是可以使用防火牆、網絡入侵監測系統或域名解析器報告可疑的 DNS 行爲跡象，作爲主動防範的措施。
先講下最常用的手段：DNS劫持和DNS污染。
什麼是DNS劫持
DNS劫持就是通過劫持了DNS服務器，通過某些手段取得某域名的解析記錄控制權，進而修改此域名的解析結果，導致對該域名的訪問由原IP地址轉入到修改後的指定IP，其結果就是對特定的網址不能訪問或訪問的是假網址，從而實現竊取資料或者破壞原有正常服務的目的。DNS劫持通過篡改DNS服務器上的數據返回給用戶一個錯誤的查詢結果來實現的。
DNS劫持症狀：在某些地區的用戶在成功連接寬帶後，首次打開任何頁面都指向ISP提供的“電信互聯星空”、“網通黃頁廣告”等內容頁面。還有就是曾經出現過用戶訪問Google域名的時候出現了百度的網站。這些都屬於DNS劫持。
什麼是DNS污染
DNS污染是一種讓一般用戶由於得到虛假目標主機IP而不能與其通信的方法，是一種DNS緩存投毒攻擊（DNS cache poisoning）。其工作方式是：由於通常的DNS查詢沒有任何認證機制，而且DNS查詢通常基於的UDP是無連接不可靠的協議，因此DNS的查詢非常容易被篡改，通過對UDP端口53上的DNS查詢進行入侵檢測，一經發現與關鍵詞相匹配的請求則立即僞裝成目標域名的解析服務器（NS，Name Server）給查詢者返回虛假結果。
而DNS污染則是發生在用戶請求的第一步上，直接從協議上對用戶的DNS請求進行干擾。
DNS污染症狀：目前一些被禁止訪問的網站很多就是通過DNS污染來實現的，例如YouTube、Facebook等網站。
解決方法:
- 對於DNS劫持，可以採用使用國外免費公用的DNS服務器解決。例如OpenDNS（208.67.222.222）或GoogleDNS（8.8.8.8）。
- 對於DNS污染，可以說，個人用戶很難單單靠設置解決，通常可以使用VPN或者域名遠程解析的方法解決，但這大多需要購買付費的VPN或SSH等，也可以通過修改Hosts的方法，手動設置域名正確的IP地址。
爲什麼要DNS流量監控
預示網絡中正出現可疑或惡意代碼的 DNS 組合查詢或流量特徵。例如：
-
1.來自僞造源地址的 DNS 查詢、或未授權使用且無出口過濾地址的 DNS 查詢，若同時觀察到異常大的 DNS 查詢量或使用 TCP 而非 UDP 進行 DNS 查詢，這可能表明網絡內存在被感染的主機，受到了 DDoS 攻擊。
-
2.異常 DNS 查詢可能是針對域名服務器或解析器（根據目標 IP 地址確定）的漏洞攻擊的標誌。與此同時，這些查詢也可能表明網絡中有不正常運行的設備。原因可能是惡意軟件或未能成功清除惡意軟件。
-
3.在很多情況下，DNS 查詢要求解析的域名如果是已知的惡意域名，或具有域名生成算法( DGA )（與非法殭屍網絡有關）常見特徵的域名，或者向未授權使用的解析器發送的查詢，都是證明網絡中存在被感染主機的有力證據。
-
4.DNS 響應也能顯露可疑或惡意數據在網絡主機間傳播的跡象。例如，DNS 響應的長度或組合特徵可以暴露惡意或非法行爲。例如，響應消息異常巨大（放大攻擊），或響應消息的 Answer Section 或 Additional Section 非常可疑（緩存污染，隱蔽通道）。
-
5.針對自身域名組合的 DNS 響應，如果解析至不同於你發佈在授權區域中的 IP 地址，或來自未授權區域主機的域名服務器的響應，或解析爲名稱錯誤( NXDOMAIN )的對區域主機名的肯定響應，均表明域名或註冊賬號可能被劫持或 DNS 響應被篡改。
-
6.來自可疑 IP 地址的 DNS 響應，例如來自分配給寬帶接入網絡 IP 段的地址、非標準端口上出現的 DNS 流量，異常大量的解析至短生存時間( TTL )域名的響應消息，或異常大量的包含“ name error ”( NXDOMAIN )的響應消息，往往是主機被殭屍網絡控制、運行惡意軟件或被感染的表現。
DNS 流量監控
如何藉助網絡入侵檢測系統、流量分析和日誌數據在網絡防火牆上應用這些機制以檢測此類威脅?
防火牆
我們從最常用的安全系統開始吧，那就是防火牆。所有的防火牆都允許自定義規則以防止 IP 地址欺騙。添加一條規則，拒絕接收來自指定範圍段以外的 IP 地址的 DNS 查詢，從而避免域名解析器被 DDOS 攻擊用作開放的反射器。
接下來，啓動 DNS 流量檢測功能，監測是否存在可疑的字節模式或異常 DNS 流量，以阻止域名服務器軟件漏洞攻擊。具備本功能的常用防火牆的介紹資料在許多網站都可以找到（例如 Palo Alto、思科、沃奇衛士等）。Sonicwall 和 Palo Alto 還可以監測並攔截特定的 DNS 隧道流量。
入侵檢測系統
無論你使用 Snort、Suricata 還是 OSSEC，都可以制定規則，要求系統對未授權客戶的 DNS 請求發送報告。你也可以制定規則來計數或報告 NXDomain 響應、包含較小 TTL 數值記錄的響應、通過 TCP 發起的 DNS 查詢、對非標準端口的 DNS 查詢和可疑的大規模 DNS 響應等。DNS 查詢或響應信息中的任何字段、任何數值基本上都“能檢測”。唯一能限制你的，就是你的想象力和對 DNS 的熟悉程度。防火牆的 IDS （入侵檢測系統）對大多數常見檢測項目都提供了允許和拒絕兩種配置規則。
流量分析工具
Wireshark 和 Bro 的實際案例都表明，被動流量分析對識別惡意軟件流量很有效果。捕獲並過濾客戶端與解析器之間的 DNS 數據，保存爲 PCAP （網絡封包）文件。創建腳本程序搜索這些網絡封包，以尋找你正在調查的某種可疑行爲。或使用 PacketQ （最初是 DNS2DB ）對網絡封包直接進行 SQL 查詢。
（記住：除了自己的本地解析器之外，禁止客戶使用任何其他解析器或非標準端口。）
DNS 被動複製
該方法涉及對解析器使用傳感器以創建數據庫，使之包含通過給定解析器或解析器組進行的所有 DNS 交易（查詢/響應）。在分析中包含 DNS 被動數據對識別惡意軟件域名有着重要作用，尤其適用於惡意軟件使用由算法生成的域名的情況。將 Suricata 用做 IDS （入侵檢測系統）引擎的 Palo Alto 防火牆和安全管理系統，正是結合使用被動 DNS 與 IPS （入侵防禦系統）以防禦已知惡意域名的安全系統範例。
解析器日誌記錄
本地解析器的日誌文件是調查 DNS 流量的最後一項，也可能是最明顯的數據來源。在開啓日誌記錄的情況下，你可以使用 Splunk 加 getwatchlist 或是 OSSEC 之類的工具收集 DNS 服務器的日誌，並搜索已知惡意域名。
儘管本文提到了不少資料鏈接、案例分析和實際例子，但也只是涉及了衆多監控 DNS 流量方法中的九牛一毛，疏漏在所難免，要想全面快捷及時有效監控 DNS 流量，不妨試試 DNS 服務器監控。
DNS 服務器監控
應用管理器可對域名系統（ DNS ）進行全面深入的可用性和性能監控，也可監控 DNS 監控器的個別屬性，比如響應時間、記錄類型、可用記錄、搜索字段、搜索值、搜索值狀態以及搜索時間等。
DNS 中被監控的一些關鍵組件：
| 指標 | 描述 |
|---|---|
| 響應時間 | 給出 DNS 監控器的響應時間，以毫秒錶示 |
| 記錄類型 | 顯示記錄類型連接到 DNS 服務器的耗時 |
| 可用記錄 | 根據可用記錄類型輸出 True 或 False |
| 搜索字段 | 顯示用於 DNS 服務器的字段類型 |
| 搜索值 | 顯示在DNS 服務器中執行的搜索值 |
| 搜索值狀態 | 根據輸出信息顯示搜索值狀態：Success (成功)或 Failed (失敗) |
| 搜索時間 | DNS 服務器中的搜索執行時間 |
監控可用性和響應時間等性能統計數據。這些數據可繪製成性能圖表和報表，即時可用，還可以按照可用性和完善性對報表進行分組顯示。
若 DNS 服務器或系統內任何特定屬性出現問題，會根據配置好的閾值生成通知和警告，並根據配置自動執行相關操作。目前，國內外 DNS 監控工具主要有 New relic、appDynamic、OneAPM。