DNS的核心工作就是將域名翻譯成計算機IP地址, 它是基于UDP協(xié)議實現(xiàn)的，本文將具體闡述DNS相關(guān)的概念，解析，調(diào)度原理（負載均衡和區(qū)域調(diào)度）等DNS相關(guān)的所有知識點。 @pdai

DNS簡介

域名系統(tǒng)并不像電話號碼通訊錄那么簡單，通訊錄主要是單個個體在使用，同一個名字出現(xiàn)在不同個體的通訊錄里并不會出現(xiàn)問題，但域名是群體中所有人都在用的，必須要保持唯一性。為了達到唯一性的目的，因特網(wǎng)在命名的時候采用了層次結(jié)構(gòu)的命名方法。每一個域名（本文只討論英文域名）都是一個標號序列（labels），用字母（A-Z，a-z，大小寫等價）、數(shù)字（0-9）和連接符（-）組成，標號序列總長度不能超過255個字符，它由點號分割成一個個的標號（label），每個標號應(yīng)該在63個字符之內(nèi)，每個標號都可以看成一個層次的域名。級別最低的域名寫在左邊，級別最高的域名寫在右邊。域名服務(wù)主要是基于UDP實現(xiàn)的，服務(wù)器的端口號為53。

域名層級結(jié)構(gòu)

注意：最開始的域名最后都是帶了點號的，比如 www.kernel.org. ，最后面的點號表示根域名服務(wù)器，后來發(fā)現(xiàn)所有的網(wǎng)址都要加上最后的點，就簡化了寫法，干脆所有的都不加即www.kernel.org，但是你在網(wǎng)址后面加上點號也是可以正常解析的。

域名服務(wù)器

有域名結(jié)構(gòu)還不行，還需要有一個東西去解析域名，手機通訊錄是由通訊錄軟件解析的，域名需要由遍及全世界的域名服務(wù)器去解析，域名服務(wù)器實際上就是裝有域名系統(tǒng)的主機。由高向低進行層次劃分，可分為以下幾大類：

• 根域名服務(wù)器：最高層次的域名服務(wù)器，也是最重要的域名服務(wù)器，本地域名服務(wù)器如果解析不了域名就會向根域名服務(wù)器求助。全球共有13個不同IP地址的根域名服務(wù)器，它們的名稱用一個英文字母命名，從a一直到m。這些服務(wù)器由各種組織控制，并由 ICANN（互聯(lián)網(wǎng)名稱和數(shù)字地址分配公司）授權(quán)，由于每分鐘都要解析的名稱數(shù)量多得令人難以置信，所以實際上每個根服務(wù)器都有鏡像服務(wù)器，每個根服務(wù)器與它的鏡像服務(wù)器共享同一個 IP 地址，中國大陸地區(qū)內(nèi)只有6組根服務(wù)器鏡像（F，I（3臺），J，L）。當你對某個根服務(wù)器發(fā)出請求時，請求會被路由到該根服務(wù)器離你最近的鏡像服務(wù)器。所有的根域名服務(wù)器都知道所有的頂級域名服務(wù)器的域名和地址，如果向根服務(wù)器發(fā)出對 “pdai.tech” 的請求，則根服務(wù)器是不能在它的記錄文件中找到與 “pdai.tech” 匹配的記錄。但是它會找到 "tech" 的頂級域名記錄，并把負責 "tech" 地址的頂級域名服務(wù)器的地址發(fā)回給請求者。
• 頂級域名服務(wù)器：負責管理在該頂級域名服務(wù)器下注冊的二級域名。當根域名服務(wù)器告訴查詢者頂級域名服務(wù)器地址時，查詢者緊接著就會到頂級域名服務(wù)器進行查詢。比如還是查詢"pdai.tech"，根域名服務(wù)器已經(jīng)告訴了查詢者"tech"頂級域名服務(wù)器的地址，"tech"頂級域名服務(wù)器會找到 “pdai.tech”的域名服務(wù)器的記錄，域名服務(wù)器檢查其區(qū)域文件，并發(fā)現(xiàn)它有與 “pdai.tech” 相關(guān)聯(lián)的區(qū)域文件。在此文件的內(nèi)部，有該主機的記錄。此記錄說明此主機所在的 IP 地址，并向請求者返回最終答案。
• 權(quán)限域名服務(wù)器：負責一個區(qū)的域名解析工作
• 本地域名服務(wù)器：當一個主機發(fā)出DNS查詢請求的時候，這個查詢請求首先就是發(fā)給本地域名服務(wù)器的。

DNS 解析流程

網(wǎng)上找了個比較好的例子

.com.fi國際金融域名DNS解析的步驟一共分為9步，如果每次解析都要走完9個步驟，大家瀏覽網(wǎng)站的速度也不會那么快，現(xiàn)在之所以能保持這么快的訪問速度，其實一般的解析都是跑完第4步就可以了。除非一個地區(qū)完全是第一次訪問（在都沒有緩存的情況下）才會走完9個步驟，這個情況很少。

• 1、本地客戶機提出域名解析請求，查找本地HOST文件后將該請求發(fā)送給本地的域名服務(wù)器。
• 2、將請求發(fā)送給本地的域名服務(wù)器。
• 3、當本地的域名服務(wù)器收到請求后，就先查詢本地的緩存。
• 4、如果有該紀錄項，則本地的域名服務(wù)器就直接把查詢的結(jié)果返回瀏覽器。
• 5、如果本地DNS緩存中沒有該紀錄，則本地域名服務(wù)器就直接把請求發(fā)給根域名服務(wù)器。
• 6、然后根域名服務(wù)器再返回給本地域名服務(wù)器一個所查詢域（根的子域）的主域名服務(wù)器的地址。
• 7、本地服務(wù)器再向上一步返回的域名服務(wù)器發(fā)送請求，然后接受請求的服務(wù)器查詢自己的緩存，如果沒有該紀錄，則返回相關(guān)的下級的域名服務(wù)器的地址。
• 8、重復(fù)第7步，直到找到正確的紀錄。
• 9、本地域名服務(wù)器把返回的結(jié)果保存到緩存，以備下一次使用，同時還將結(jié)果返回給客戶機。

注意事項：

遞歸查詢：在該模式下DNS服務(wù)器接收到客戶機請求，必須使用一個準確的查詢結(jié)果回復(fù)客戶機。如果DNS服務(wù)器本地沒有存儲查詢DNS信息，那么該服務(wù)器會詢問其他服務(wù)器，并將返回的查詢結(jié)果提交給客戶機。

迭代查詢：DNS所在服務(wù)器若沒有可以響應(yīng)的結(jié)果，會向客戶機提供其他能夠解析查詢請求的DNS服務(wù)器地址，當客戶機發(fā)送查詢請求時，DNS服務(wù)器并不直接回復(fù)查詢結(jié)果，而是告訴客戶機另一臺DNS服務(wù)器地址，客戶機再向這臺DNS服務(wù)器提交請求，依次循環(huán)直到返回查詢的結(jié)果為止。

為什么DNS通?；赨DP

使用基于UDP的DNS協(xié)議只要一個請求、一個應(yīng)答就好了

而使用基于TCP的DNS協(xié)議要三次握手、發(fā)送數(shù)據(jù)以及應(yīng)答、四次揮手

明顯基于TCP協(xié)議的DNS更浪費網(wǎng)絡(luò)資源！

當然以上只是從數(shù)據(jù)包的數(shù)量以及占有網(wǎng)絡(luò)資源的層面來進行的分析，那數(shù)據(jù)一致性層面呢？

DNS數(shù)據(jù)包不是那種大數(shù)據(jù)包，所以使用UDP不需要考慮分包，如果丟包那么就是全部丟包，如果收到了數(shù)據(jù)，那就是收到了全部數(shù)據(jù)！所以只需要考慮丟包的情況，那就算是丟包了，重新請求一次就好了。而且DNS的報文允許填入序號字段，對于請求報文和其對應(yīng)的應(yīng)答報文，這個字段是相同的，通過它可以區(qū)分DNS應(yīng)答是對應(yīng)的哪個請求

DNS通常是基于UDP的，但當數(shù)據(jù)長度大于512字節(jié)的時候，為了保證傳輸質(zhì)量，就會使用基于TCP的實現(xiàn)方式

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之間的對應(yīng)關(guān)系，稱為"記錄"（record）。根據(jù)使用場景，"記錄"可以分成不同的類型（type），前面已經(jīng)看到了有A記錄和NS記錄。

常見的DNS記錄類型如下。

• A：地址記錄（Address），返回域名指向的IP地址。
• NS：域名服務(wù)器記錄（Name Server），返回保存下一級域名信息的服務(wù)器地址。該記錄只能設(shè)置為域名，不能設(shè)置為IP地址。
• MX：郵件記錄（Mail eXchange），返回接收電子郵件的服務(wù)器地址。
• CNAME：規(guī)范名稱記錄（Canonical Name），返回另一個域名，即當前查詢的域名是另一個域名的跳轉(zhuǎn)，詳見下文。
• PTR：逆向查詢記錄（Pointer Record），只用于從IP地址查詢域名，詳見下文。

一般來說，為了服務(wù)的安全可靠，至少應(yīng)該有兩條NS記錄，而A記錄和MX記錄也可以有多條，這樣就提供了服務(wù)的冗余性，防止出現(xiàn)單點失敗。

CNAME記錄主要用于域名的內(nèi)部跳轉(zhuǎn)，為服務(wù)器配置提供靈活性，用戶感知不到。

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:       info@verisign-grs.com

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:       info@verisign-grs.com

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 <<<

DNS 調(diào)度原理

本節(jié)轉(zhuǎn)自：【網(wǎng)易MC】DNS 調(diào)度原理解析

現(xiàn)在，大部分應(yīng)用和業(yè)務(wù)都采用域名作為服務(wù)的入口，因此用 DNS 來負載均衡和區(qū)域調(diào)度是非常普遍的做法，網(wǎng)易云也有著一套基于 DNS 的調(diào)度系統(tǒng)。某些用戶在進行直播推流時用的并不是網(wǎng)易云的直播 SDK，而是一些第三方的推流軟件，如obs，這樣就不能使用我們的 GSLB 全局調(diào)度服務(wù)器來調(diào)度。對于這些用戶，我們使用 DNS 調(diào)度的方式，對不同地域的請求返回不同解析結(jié)果，將請求調(diào)度到離用戶最近的服務(wù)器節(jié)點，從而減少延遲訪問。

咋一看，DNS 調(diào)度這么簡單方便，那為什么不讓所有的用戶都走 DNS 調(diào)度呢？想知道原因？來，我們繼續(xù)講。

地理位置調(diào)度不準確

在 DNS 解析過程中，與權(quán)威服務(wù)器通信的只有 DNS 緩存服務(wù)器，所以權(quán)威服務(wù)器只能根據(jù) DNS 緩存服務(wù)器的IP來進行調(diào)度。因此 DNS 調(diào)度有一個前提：假定用戶使用的緩存DNS與用戶本身在同個網(wǎng)絡(luò)內(nèi)，即至少在同一個 AS(自治域)內(nèi)，在該前提下，DNS 的解析才是準確的。通常情況下，用戶使用 ISP 提供的本地緩存(簡稱 local DNS)，local DNS 一般與用戶在同個網(wǎng)絡(luò)內(nèi)，這時候 DNS 調(diào)度是有效的。

但近些年，不少互聯(lián)網(wǎng)廠商推廣基于 BGP Anycast 的公共 DNS (Public DNS)，而這些Anycaset IP 的節(jié)點一般是遠少于各個ISP的節(jié)點，例如可能廣州電信用戶使用了某公共 DNS，但該公共 DNS 里用戶最近的是上海電信節(jié)點，甚至更極端的如 Google DNS 8.8.8.8，在中國大陸沒有節(jié)點(最近的是臺灣)。而不幸的是國內(nèi)有不少用戶使用了 Google DNS，這其實降低了他們的網(wǎng)絡(luò)訪問體驗?？偟膩碚f，使用公共 DNS，實際上破壞了上文的前提，導(dǎo)致 DNS 區(qū)域調(diào)度失效，用戶以為得到了更快更安全的 DNS 解析，但實際得到了錯誤的解析，增加了網(wǎng)絡(luò)訪問延遲。

傳統(tǒng) DNS 協(xié)議的區(qū)域調(diào)度過程示例如下圖，假定某業(yè)務(wù)以 foo.163.com 對外提供服務(wù)，在北京和東京各有一個節(jié)點，業(yè)務(wù)期望國內(nèi)大陸的用戶訪問北京節(jié)點，而非大陸用戶則訪問東京節(jié)點。因為權(quán)威是根據(jù) DNS 緩存來決定返回的結(jié)果，所以當用戶使用不用的 DNS 緩存時，可能會解析到不同的結(jié)果。

2011 年，Google 為首的幾家公司在提出了一個 DNS 的擴展方案 edns-client-subnet (以下簡稱 ECS)，該擴展方案的核心思想是通過在 DNS 請求報文里加入原始請求的 IP(即 client 的 IP)，使得權(quán)威能根據(jù)該信息返回正確的結(jié)果。目前，該方案仍處于草案階段。該方案很好地解決了上述提到的 remote DNS 導(dǎo)致解析不準確的問題，但也帶了一些問題：

• 至少需要 cache 和權(quán)威都支持，才能完成完整的 ECS 解析
• ECS 給 cache 增加了很大的緩存壓力，因為理論上可能需要為每個IP段分配空間去緩存解析結(jié)果

規(guī)則變更生效時間不確定

當緩存服務(wù)器向權(quán)威服務(wù)器查詢得到記錄之后，會將其緩存起來，在緩存有效期內(nèi)，如果收到相同記錄的查詢，緩存服務(wù)器會直接返回給客戶端，而不需要再次向權(quán)威查詢，當有效期過后，緩存則是需要再次發(fā)起查詢。這個緩存有效期即是 TTL。

雖然 DNS 的緩存機制在大多數(shù)情況下縮短了客戶端的記錄解析時間，但緩存也意味著生效同步的延遲。當權(quán)威服務(wù)器的記錄變更時，需要等待一段時間才能讓所有客戶端能解析到新的結(jié)果，因為很可能緩存服務(wù)器還緩存著舊的記錄。

我們將權(quán)威的記錄變更到全網(wǎng)生效這個過程稱為 propagation，它的時間是不確定的，理論上的最大值即是 TTL 的值，對于記錄變更或刪除，這個時間是記錄原本的 TTL，對于記錄新增則是域的 nTTL 值。

如果一個域名記錄原本的 TTL 是 18000，可以認為，變更該記錄理論上需要等待 5 個小時才能保證記錄能生效到全網(wǎng)。假設(shè)該域名的業(yè)務(wù)方希望縮短切換的時間，正確的做法是，至少提前5個小時修改記錄，僅改小 TTL，例如改為5分鐘，等待該變更同步到全網(wǎng)之后，再進行修改指向的操作，確認無誤再將 TTL 修改為原本的值。

雖然 DNS 協(xié)議標準里建議緩存服務(wù)器應(yīng)該記住或者縮短 TTL 的值，但實際上，有一些DNS緩存會修改權(quán)威服務(wù)器的 TTL，將其變大，這在國內(nèi)幾大運營商中是很常見的。例如，某域記錄的 TTL 值實際上設(shè)置為 60，但在運營商的 DNS 緩存上，卻變成 600 或者更大的值，甚至還有一些 DNS 緩存是不遵循 TTL 機制。這些都會影響域名的實際生效時間。

高可用

為避免受 DNS 緩存的影響，需要保證 DNS 中 A 記錄的 IP 節(jié)點高可用性。對此，網(wǎng)易云DNS 調(diào)度系統(tǒng)采用的方案是在同一區(qū)域的多臺直播服務(wù)器節(jié)點之間做負載均衡，對外只暴露一個虛 IP，這樣，即使某臺服務(wù)器宕機，負載均衡能迅速感知到，排除故障節(jié)點，而對 DNS 而言，因為虛 IP 不變而不受影響。

DNS 安全相關(guān)

本章節(jié)部分內(nèi)容參考自： OneAPM blog

犯罪分子會抓住任何互聯(lián)網(wǎng)服務(wù)或協(xié)議的漏洞發(fā)動攻擊，這當然也包括域名系統(tǒng)（ DNS ）。他們會注冊一次性域名用于垃圾郵件活動和僵尸網(wǎng)絡(luò)管理，還會盜用域名進行釣魚和惡意軟件下載。他們會注入惡意查詢代碼以利用域名服務(wù)器的漏洞或擾亂域名解析過程。他們會注入偽造的響應(yīng)污染解析器緩存或強化 DDOS 攻擊。他們甚至將 DNS 用作數(shù)據(jù)滲漏或惡意軟件更新的隱蔽通道。

你可能沒辦法了解每一個新的 DNS 漏洞攻擊，但是可以使用防火墻、網(wǎng)絡(luò)入侵監(jiān)測系統(tǒng)或域名解析器報告可疑的 DNS 行為跡象，作為主動防范的措施。

先講下最常用的手段：DNS劫持和DNS污染。

什么是DNS劫持

DNS劫持就是通過劫持了DNS服務(wù)器，通過某些手段取得某域名的解析記錄控制權(quán)，進而修改此域名的解析結(jié)果，導(dǎo)致對該域名的訪問由原IP地址轉(zhuǎn)入到修改后的指定IP，其結(jié)果就是對特定的網(wǎng)址不能訪問或訪問的是假網(wǎng)址，從而實現(xiàn)竊取資料或者破壞原有正常服務(wù)的目的。DNS劫持通過篡改DNS服務(wù)器上的數(shù)據(jù)返回給用戶一個錯誤的查詢結(jié)果來實現(xiàn)的。

DNS劫持癥狀：在某些地區(qū)的用戶在成功連接寬帶后，首次打開任何頁面都指向ISP提供的“電信互聯(lián)星空”、“網(wǎng)通黃頁廣告”等內(nèi)容頁面。還有就是曾經(jīng)出現(xiàn)過用戶訪問Google域名的時候出現(xiàn)了百度的網(wǎng)站。這些都屬于DNS劫持。

什么是DNS污染

DNS污染是一種讓一般用戶由于得到虛假目標主機IP而不能與其通信的方法，是一種DNS緩存投毒攻擊（DNS cache poisoning）。其工作方式是：由于通常的DNS查詢沒有任何認證機制，而且DNS查詢通常基于的UDP是無連接不可靠的協(xié)議，因此DNS的查詢非常容易被篡改，通過對UDP端口53上的DNS查詢進行入侵檢測，一經(jīng)發(fā)現(xiàn)與關(guān)鍵詞相匹配的請求則立即偽裝成目標域名的解析服務(wù)器（NS，Name Server）給查詢者返回虛假結(jié)果。

而DNS污染則是發(fā)生在用戶請求的第一步上，直接從協(xié)議上對用戶的DNS請求進行干擾。

DNS污染癥狀：目前一些被禁止訪問的網(wǎng)站很多就是通過DNS污染來實現(xiàn)的，例如YouTube、Facebook等網(wǎng)站。

解決方法:

• 對于DNS劫持，可以采用使用國外免費公用的DNS服務(wù)器解決。例如OpenDNS（208.67.222.222）或GoogleDNS（8.8.8.8）。
• 對于DNS污染，可以說，個人用戶很難單單靠設(shè)置解決，通?？梢允褂肰PN或者域名遠程解析的方法解決，但這大多需要購買付費的VPN或SSH等，也可以通過修改Hosts的方法，手動設(shè)置域名正確的IP地址。

為什么要DNS流量監(jiān)控

預(yù)示網(wǎng)絡(luò)中正出現(xiàn)可疑或惡意代碼的 DNS 組合查詢或流量特征。例如：

• 1.來自偽造源地址的 DNS 查詢、或未授權(quán)使用且無出口過濾地址的 DNS 查詢，若同時觀察到異常大的 DNS 查詢量或使用 TCP 而非 UDP 進行 DNS 查詢，這可能表明網(wǎng)絡(luò)內(nèi)存在被感染的主機，受到了 DDoS 攻擊。
• 2.異常 DNS 查詢可能是針對域名服務(wù)器或解析器（根據(jù)目標 IP 地址確定）的漏洞攻擊的標志。與此同時，這些查詢也可能表明網(wǎng)絡(luò)中有不正常運行的設(shè)備。原因可能是惡意軟件或未能成功清除惡意軟件。
• 3.在很多情況下，DNS 查詢要求解析的域名如果是已知的惡意域名，或具有域名生成算法( DGA )（與非法僵尸網(wǎng)絡(luò)有關(guān)）常見特征的域名，或者向未授權(quán)使用的解析器發(fā)送的查詢，都是證明網(wǎng)絡(luò)中存在被感染主機的有力證據(jù)。
• 4.DNS 響應(yīng)也能顯露可疑或惡意數(shù)據(jù)在網(wǎng)絡(luò)主機間傳播的跡象。例如，DNS 響應(yīng)的長度或組合特征可以暴露惡意或非法行為。例如，響應(yīng)消息異常巨大（放大攻擊），或響應(yīng)消息的 Answer Section 或 Additional Section 非?？梢桑ň彺嫖廴?，隱蔽通道）。
• 5.針對自身域名組合的 DNS 響應(yīng)，如果解析至不同于你發(fā)布在授權(quán)區(qū)域中的 IP 地址，或來自未授權(quán)區(qū)域主機的域名服務(wù)器的響應(yīng)，或解析為名稱錯誤( NXDOMAIN )的對區(qū)域主機名的肯定響應(yīng)，均表明域名或注冊賬號可能被劫持或 DNS 響應(yīng)被篡改。
• 6.來自可疑 IP 地址的 DNS 響應(yīng)，例如來自分配給寬帶接入網(wǎng)絡(luò) IP 段的地址、非標準端口上出現(xiàn)的 DNS 流量，異常大量的解析至短生存時間( TTL )域名的響應(yīng)消息，或異常大量的包含“ name error ”( NXDOMAIN )的響應(yīng)消息，往往是主機被僵尸網(wǎng)絡(luò)控制、運行惡意軟件或被感染的表現(xiàn)。

DNS 流量監(jiān)控

如何借助網(wǎng)絡(luò)入侵檢測系統(tǒng)、流量分析和日志數(shù)據(jù)在網(wǎng)絡(luò)防火墻上應(yīng)用這些機制以檢測此類威脅?

防火墻

我們從最常用的安全系統(tǒng)開始吧，那就是防火墻。所有的防火墻都允許自定義規(guī)則以防止 IP 地址欺騙。添加一條規(guī)則，拒絕接收來自指定范圍段以外的 IP 地址的 DNS 查詢，從而避免域名解析器被 DDOS 攻擊用作開放的反射器。

接下來，啟動 DNS 流量檢測功能，監(jiān)測是否存在可疑的字節(jié)模式或異常 DNS 流量，以阻止域名服務(wù)器軟件漏洞攻擊。具備本功能的常用防火墻的介紹資料在許多網(wǎng)站都可以找到（例如 Palo Alto、思科、沃奇衛(wèi)士等）。Sonicwall 和 Palo Alto 還可以監(jiān)測并攔截特定的 DNS 隧道流量。

入侵檢測系統(tǒng)

無論你使用 Snort、Suricata 還是 OSSEC，都可以制定規(guī)則，要求系統(tǒng)對未授權(quán)客戶的 DNS 請求發(fā)送報告。你也可以制定規(guī)則來計數(shù)或報告 NXDomain 響應(yīng)、包含較小 TTL 數(shù)值記錄的響應(yīng)、通過 TCP 發(fā)起的 DNS 查詢、對非標準端口的 DNS 查詢和可疑的大規(guī)模 DNS 響應(yīng)等。DNS 查詢或響應(yīng)信息中的任何字段、任何數(shù)值基本上都“能檢測”。唯一能限制你的，就是你的想象力和對 DNS 的熟悉程度。防火墻的 IDS （入侵檢測系統(tǒng)）對大多數(shù)常見檢測項目都提供了允許和拒絕兩種配置規(guī)則。

流量分析工具

Wireshark 和 Bro 的實際案例都表明，被動流量分析對識別惡意軟件流量很有效果。捕獲并過濾客戶端與解析器之間的 DNS 數(shù)據(jù)，保存為 PCAP （網(wǎng)絡(luò)封包）文件。創(chuàng)建腳本程序搜索這些網(wǎng)絡(luò)封包，以尋找你正在調(diào)查的某種可疑行為?；蚴褂?PacketQ （最初是 DNS2DB ）對網(wǎng)絡(luò)封包直接進行 SQL 查詢。

（記?。撼俗约旱谋镜亟馕銎髦?，禁止客戶使用任何其他解析器或非標準端口。）

DNS 被動復(fù)制

該方法涉及對解析器使用傳感器以創(chuàng)建數(shù)據(jù)庫，使之包含通過給定解析器或解析器組進行的所有 DNS 交易（查詢/響應(yīng)）。在分析中包含 DNS 被動數(shù)據(jù)對識別惡意軟件域名有著重要作用，尤其適用于惡意軟件使用由算法生成的域名的情況。將 Suricata 用做 IDS （入侵檢測系統(tǒng)）引擎的 Palo Alto 防火墻和安全管理系統(tǒng)，正是結(jié)合使用被動 DNS 與 IPS （入侵防御系統(tǒng)）以防御已知惡意域名的安全系統(tǒng)范例。

解析器日志記錄

本地解析器的日志文件是調(diào)查 DNS 流量的最后一項，也可能是最明顯的數(shù)據(jù)來源。在開啟日志記錄的情況下，你可以使用 Splunk 加 getwatchlist 或是 OSSEC 之類的工具收集 DNS 服務(wù)器的日志，并搜索已知惡意域名。

盡管本文提到了不少資料鏈接、案例分析和實際例子，但也只是涉及了眾多監(jiān)控 DNS 流量方法中的九牛一毛，疏漏在所難免，要想全面快捷及時有效監(jiān)控 DNS 流量，不妨試試 DNS 服務(wù)器監(jiān)控。

DNS 服務(wù)器監(jiān)控

應(yīng)用管理器可對域名系統(tǒng)（ DNS ）進行全面深入的可用性和性能監(jiān)控，也可監(jiān)控 DNS 監(jiān)控器的個別屬性，比如響應(yīng)時間、記錄類型、可用記錄、搜索字段、搜索值、搜索值狀態(tài)以及搜索時間等。

DNS 中被監(jiān)控的一些關(guān)鍵組件：

指標 描述 響應(yīng)時間 給出 DNS 監(jiān)控器的響應(yīng)時間，以毫秒表示 記錄類型 顯示記錄類型連接到 DNS 服務(wù)器的耗時 可用記錄 根據(jù)可用記錄類型輸出 True 或 False 搜索字段 顯示用于 DNS 服務(wù)器的字段類型 搜索值 顯示在DNS 服務(wù)器中執(zhí)行的搜索值 搜索值狀態(tài) 根據(jù)輸出信息顯示搜索值狀態(tài)：Success (成功)或 Failed (失敗) 搜索時間 DNS 服務(wù)器中的搜索執(zhí)行時間

監(jiān)控可用性和響應(yīng)時間等性能統(tǒng)計數(shù)據(jù)。這些數(shù)據(jù)可繪制成性能圖表和報表，即時可用，還可以按照可用性和完善性對報表進行分組顯示。

若 DNS 服務(wù)器或系統(tǒng)內(nèi)任何特定屬性出現(xiàn)問題，會根據(jù)配置好的閾值生成通知和警告，并根據(jù)配置自動執(zhí)行相關(guān)操作。目前，國內(nèi)外 DNS 監(jiān)控工具主要有 New relic、appDynamic、OneAPM。

參考文章

• 【網(wǎng)易MC】DNS 調(diào)度原理解析
• DNS 原理入門
• DNS原理及其解析過程【精彩剖析】
• 當我們談網(wǎng)絡(luò)時，我們談些什么(2)–DNS的工作原理
• 企業(yè)如何抵御利用DNS隧道的惡意軟件?
• 監(jiān)控 DNS 流量，預(yù)防安全隱患五大招！
• DNS協(xié)議詳解及報文格式分析