DNS的解析,查詢,調(diào)度原理是什么?什么是DNS劫持,污染?如何...
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)的命名方法。每一個域名（本文只討論英文域名）都是一個標(biāo)號序列（labels），用字母（A-Z，a-z，大小寫等價）、數(shù)字（0-9）和連接符（-）組成，標(biāo)號序列總長度不能超過255個字符，它由點號分割成一個個的標(biāo)號（label），每個標(biāo)號應(yīng)該在63個字符之內(nèi)，每個標(biāo)號都可以看成一個層次的域名。級別最低的域名寫在左邊，級別最高的域名寫在右邊。域名服務(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）。當(dāng)你對某個根服務(wù)器發(fā)出請求時，請求會被路由到該根服務(wù)器離你最近的鏡像服務(wù)器。所有的根域名服務(wù)器都知道所有的頂級域名服務(wù)器的域名和地址，如果向根服務(wù)器發(fā)出對 “pdai.tech” 的請求，則根服務(wù)器是不能在它的記錄文件中找到與 “pdai.tech” 匹配的記錄。但是它會找到 "tech" 的頂級域名記錄，并把負責(zé) "tech" 地址的頂級域名服務(wù)器的地址發(fā)回給請求者。
- 頂級域名服務(wù)器：負責(zé)管理在該頂級域名服務(wù)器下注冊的二級域名。當(dāng)根域名服務(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ù)器：負責(zé)一個區(qū)的域名解析工作
- 本地域名服務(wù)器：當(dāng)一個主機發(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、當(dāng)本地的域名服務(wù)器收到請求后，就先查詢本地的緩存。
- 4、如果有該紀(jì)錄項，則本地的域名服務(wù)器就直接把查詢的結(jié)果返回瀏覽器。
- 5、如果本地DNS緩存中沒有該紀(jì)錄，則本地域名服務(wù)器就直接把請求發(fā)給根域名服務(wù)器。
- 6、然后根域名服務(wù)器再返回給本地域名服務(wù)器一個所查詢域（根的子域）的主域名服務(wù)器的地址。
- 7、本地服務(wù)器再向上一步返回的域名服務(wù)器發(fā)送請求，然后接受請求的服務(wù)器查詢自己的緩存，如果沒有該紀(jì)錄，則返回相關(guān)的下級的域名服務(wù)器的地址。
- 8、重復(fù)第7步，直到找到正確的紀(jì)錄。
- 9、本地域名服務(wù)器把返回的結(jié)果保存到緩存，以備下一次使用，同時還將結(jié)果返回給客戶機。
注意事項：
遞歸查詢：在該模式下DNS服務(wù)器接收到客戶機請求，必須使用一個準(zhǔn)確的查詢結(jié)果回復(fù)客戶機。如果DNS服務(wù)器本地沒有存儲查詢DNS信息，那么該服務(wù)器會詢問其他服務(wù)器，并將返回的查詢結(jié)果提交給客戶機。
迭代查詢：DNS所在服務(wù)器若沒有可以響應(yīng)的結(jié)果，會向客戶機提供其他能夠解析查詢請求的DNS服務(wù)器地址，當(dāng)客戶機發(fā)送查詢請求時，DNS服務(wù)器并不直接回復(fù)查詢結(jié)果，而是告訴客戶機另一臺DNS服務(wù)器地址，客戶機再向這臺DNS服務(wù)器提交請求，依次循環(huán)直到返回查詢的結(jié)果為止。
為什么DNS通常基于UDP
使用基于UDP的DNS協(xié)議只要一個請求、一個應(yīng)答就好了
而使用基于TCP的DNS協(xié)議要三次握手、發(fā)送數(shù)據(jù)以及應(yīng)答、四次揮手
明顯基于TCP協(xié)議的DNS更浪費網(wǎng)絡(luò)資源！
當(dāng)然以上只是從數(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的，但當(dāng)數(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），返回另一個域名，即當(dāng)前查詢的域名是另一個域名的跳轉(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:[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 調(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)度不準(zhǔn)確
在 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 的解析才是準(zhǔn)確的。通常情況下，用戶使用 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ò)訪問體驗。總的來說，使用公共 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é)果，所以當(dāng)用戶使用不用的 DNS 緩存時，可能會解析到不同的結(jié)果。
2011 年，Google 為首的幾家公司在提出了一個 DNS 的擴展方案 edns-client-subnet (以下簡稱 ECS)，該擴展方案的核心思想是通過在 DNS 請求報文里加入原始請求的 IP(即 client 的 IP)，使得權(quán)威能根據(jù)該信息返回正確的結(jié)果。目前，該方案仍處于草案階段。該方案很好地解決了上述提到的 remote DNS 導(dǎo)致解析不準(zhǔn)確的問題，但也帶了一些問題：
- 至少需要 cache 和權(quán)威都支持，才能完成完整的 ECS 解析
- ECS 給 cache 增加了很大的緩存壓力，因為理論上可能需要為每個IP段分配空間去緩存解析結(jié)果
規(guī)則變更生效時間不確定
當(dāng)緩存服務(wù)器向權(quán)威服務(wù)器查詢得到記錄之后，會將其緩存起來，在緩存有效期內(nèi)，如果收到相同記錄的查詢，緩存服務(wù)器會直接返回給客戶端，而不需要再次向權(quán)威查詢，當(dāng)有效期過后，緩存則是需要再次發(fā)起查詢。這個緩存有效期即是 TTL。
雖然 DNS 的緩存機制在大多數(shù)情況下縮短了客戶端的記錄解析時間，但緩存也意味著生效同步的延遲。當(dāng)權(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é)議標(biāo)準(zhǔn)里建議緩存服務(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ā)動攻擊，這當(dāng)然也包括域名系統(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污染是一種讓一般用戶由于得到虛假目標(biāo)主機IP而不能與其通信的方法，是一種DNS緩存投毒攻擊（DNS cache poisoning）。其工作方式是：由于通常的DNS查詢沒有任何認證機制，而且DNS查詢通常基于的UDP是無連接不可靠的協(xié)議，因此DNS的查詢非常容易被篡改，通過對UDP端口53上的DNS查詢進行入侵檢測，一經(jīng)發(fā)現(xiàn)與關(guān)鍵詞相匹配的請求則立即偽裝成目標(biāo)域名的解析服務(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è)置解決，通常可以使用VPN或者域名遠程解析的方法解決，但這大多需要購買付費的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ù)目標(biāo) IP 地址確定）的漏洞攻擊的標(biāo)志。與此同時，這些查詢也可能表明網(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 段的地址、非標(biāo)準(zhǔn)端口上出現(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 查詢、對非標(biāo)準(zhǔn)端口的 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 查詢。
（記?。撼俗约旱谋镜亟馕銎髦?，禁止客戶使用任何其他解析器或非標(biāo)準(zhǔn)端口。）
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)鍵組件：
| 指標(biāo) | 描述 |
|---|---|
| 響應(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。
參考文章
本文參考了如下內(nèi)容：
- 【網(wǎng)易MC】DNS 調(diào)度原理解析
- DNS 原理入門
- DNS原理及其解析過程【精彩剖析】
- 當(dāng)我們談網(wǎng)絡(luò)時，我們談些什么(2)--DNS的工作原理
- 企業(yè)如何抵御利用DNS隧道的惡意軟件?
- 監(jiān)控 DNS 流量，預(yù)防安全隱患五大招！
- DNS協(xié)議詳解及報文格式分析