◆魏 遠(yuǎn) 張 平

（信息工程大學(xué) 河南 450001）

典型的DNS威脅與防御技術(shù)研究

◆魏 遠(yuǎn) 張 平

（信息工程大學(xué) 河南 450001）

DNS是互聯(lián)網(wǎng)中最重要的基礎(chǔ)設(shè)施，但由于其自身設(shè)計(jì)缺陷，針對(duì)其安全漏洞的網(wǎng)絡(luò)攻擊事件層出不窮。本文介紹了DNS協(xié)議基礎(chǔ)框架和其存在的安全漏洞，討論了基于這些漏洞實(shí)現(xiàn)的典型攻擊方式，包括反射放大攻擊，DNS劫持，緩存投毒攻擊，DNS隧道等，在分析攻擊實(shí)現(xiàn)原理和危害的基礎(chǔ)上，給出了相應(yīng)的抗攻擊方法和建議。

DNS；域名系統(tǒng)威脅；反射放大攻擊；緩存投毒；DNSSEC

0 引言

互聯(lián)網(wǎng)已經(jīng)成為我們生活中必不可少的一部分，而 DNS（Domain Name System，域名系統(tǒng)）[1，2]是互聯(lián)網(wǎng)運(yùn)行的最重要的基礎(chǔ)設(shè)施，在全球互聯(lián)網(wǎng)的運(yùn)轉(zhuǎn)中扮演基礎(chǔ)性作用?；ヂ?lián)網(wǎng)中的任何一個(gè)事件幾乎都開始于一次 DNS查詢，盡管這一切都是無形中完成的。DNS的最主要的功能是將人類更好辨識(shí)的域名轉(zhuǎn)換為數(shù)字化的IP地址。DNS在設(shè)計(jì)之初，互聯(lián)網(wǎng)規(guī)模并沒有如今這么龐大，但隨著計(jì)算機(jī)和互聯(lián)網(wǎng)技術(shù)的逐步發(fā)展，DNS固有的安全缺陷逐步暴漏出來，由此引發(fā)越來越多的網(wǎng)絡(luò)安全問題。DNS最主要問題在于通信雙方缺乏來源數(shù)據(jù)真實(shí)性和完整性的認(rèn)證機(jī)制，系統(tǒng)無法確認(rèn)數(shù)據(jù)發(fā)送方是否是合法的發(fā)送方，也無法驗(yàn)證數(shù)據(jù)報(bào)是否被篡改，攻擊者很容易實(shí)現(xiàn)源地址和數(shù)據(jù)內(nèi)容的欺騙。

本文的重點(diǎn)討論DNS所面臨的典型的威脅，包括基于DNS的分布式拒絕服務(wù)攻擊，DNS劫持，DNS緩存投毒，DNS隧道等，在分析在典型DNS的攻擊技術(shù)的實(shí)現(xiàn)原理和危害程度的基礎(chǔ)上，給出了相應(yīng)的防御措施和緩解措施，如 DNS安全擴(kuò)展，任撥，響應(yīng)率限制等。

1 DNS基礎(chǔ)概覽

DNS是一個(gè)全球性的龐大系統(tǒng)，其核心的原件主要包含域名空間（Name Space）、名稱服務(wù)器（Name Server）、資源記錄（Resource Record）、解析器（Resolver）。

DNS域名空間類似于Unix文件系統(tǒng)，是一種自上而下的樹狀組織方式[3]，如圖1所示。根節(jié)點(diǎn)在最頂層，樹狀結(jié)構(gòu)的第一層包含有“.com”，“.net”等頂級(jí)域名，第二層包含通用域名如“baidu.com”，第三層是子域名或者具體主機(jī)，當(dāng)然也可以有第四層甚至更多的層。需要注意的是，每個(gè)域名都可以被劃分為多個(gè)子域名。

圖1 域名空間結(jié)構(gòu)

除了域名空間自身，域名空間所代表的信息需要被存儲(chǔ)在某些載體上，名稱服務(wù)器正是存儲(chǔ)這些域名空間的信息的載體。名稱服務(wù)器通常被劃分為權(quán)威名稱服務(wù)器和遞歸名稱服務(wù)器。對(duì)于一個(gè)特定的域名空間，如果一個(gè)名稱服務(wù)器有這個(gè)域名空間的所有的信息，則將這個(gè)名稱服務(wù)器稱為這個(gè)域名空間的權(quán)威名稱服務(wù)器，否則稱為遞歸名稱服務(wù)器。

在 DNS系統(tǒng)中，解析器也是一個(gè)重要的角色，通常用戶所直接使用的也是解析器，例如，谷歌的“8.8.8.8”，國(guó)內(nèi)的“114.114.114.114”等都是最常用的解析器。解析器在用戶和名稱服務(wù)器之間扮演橋梁的作用，其最重要的任務(wù)是，接受用戶的查詢請(qǐng)求，向名稱服務(wù)器查詢具體地址，解析來自于名稱服務(wù)器的響應(yīng)，然后再返回結(jié)果給用戶。對(duì)于用戶來說，解析器是服務(wù)器端，對(duì)于名稱服務(wù)器而言，解析器又是客戶端。

資源記錄包含和域名相關(guān)的各項(xiàng)數(shù)據(jù)，資源記錄包含很多種類，但常用的是internet類（IN類），這種類包含多種不同的數(shù)據(jù)類型，表1給出了最常見的幾種IN類資源記錄。

表1 常見資源記錄

為了更加直觀展現(xiàn)DNS工作流程，下面以訪問baidu.com為例說明DNS運(yùn)轉(zhuǎn)過程：

（1）當(dāng)用戶想要接入baidu.com時(shí)，問解析器，“請(qǐng)告訴我baidu.com的IP地址？”。

（2）解析器接到用戶查詢請(qǐng)求后，解析器首先會(huì)查詢自身的緩存記錄是否有baidu.com的地址記錄，如果有并且尚未過期，則直接返回給用戶，如果沒有，則解析器會(huì)轉(zhuǎn)向根名稱服務(wù)器，詢問根名稱服務(wù)器，“請(qǐng)告訴我baidu.com的IP地址？”。

（3）根名稱服務(wù)器收到請(qǐng)求后，會(huì)根據(jù)域名的頂級(jí)名稱空間判斷，發(fā)現(xiàn) baidu.com的頂級(jí)名稱空間是.com，則會(huì)通知解析器，“請(qǐng)?jiān)儐?com名稱服務(wù)器”。

（4）解析器再次轉(zhuǎn)向.com名稱服務(wù)器，然后問同樣的問題。

（5）.com名稱服務(wù)器會(huì)根據(jù)域名判斷，發(fā)現(xiàn)baidu.com這個(gè)域名的權(quán)威名稱服務(wù)器是ns.baidu.com，它會(huì)給解析器回答，“請(qǐng)?jiān)儐杗s.baidu.com名稱服務(wù)器”。

（6）解析器再次轉(zhuǎn)向ns.baidu.com名稱服務(wù)器，然后問同樣的問題，ns.baidu.com屬于 baidu.com的權(quán)威服務(wù)器，它擁有baidu.com的所有的信息，當(dāng)然也知道baidu.com的地址，直接回答出baidu.com的IP地址。

（7）最終，解析器得到了baidu.com的IP地址，轉(zhuǎn)發(fā)給用戶，在自身緩存表中存入或更新，以便下次查詢。

圖2 DNS工作流程

值得一提的是，一定要注意到緩存記錄，當(dāng)解析器中有對(duì)應(yīng)域名的緩存記錄，并且緩存沒有過期時(shí)，它會(huì)直接將緩存記錄中的域名返回給用戶，而無需再向其他名稱服務(wù)器詢問，緩存記錄可以增強(qiáng)整個(gè)系統(tǒng)的可擴(kuò)展性和減少解析延遲，但同時(shí)由于缺乏安全保護(hù)，也隱藏著其他安全問題。

2 DNS面臨的典型威脅

DNS在設(shè)計(jì)之初的核心關(guān)注點(diǎn)在于系統(tǒng)的穩(wěn)定性，容錯(cuò)性，可擴(kuò)展性等，并沒有考慮安全的問題，這種固有的設(shè)計(jì)缺陷滋生了多種安全漏洞，概括而言，DNS主要存在以下幾個(gè)問題：

（1）無論是查詢請(qǐng)求還是查詢響應(yīng)，數(shù)據(jù)都是通過既沒有簽名，也沒有加密的 UDP協(xié)議來傳送的，很容易遭到竊聽和篡改。

（2）對(duì)通信雙方而言，都沒有辦法驗(yàn)證對(duì)方數(shù)據(jù)來源的真實(shí)性和完整性。

（3）DNS使用緩存來加快解析進(jìn)度，但同時(shí)也因?yàn)榫彺鏇]有足夠保護(hù)機(jī)制，導(dǎo)致緩存數(shù)據(jù)成為重點(diǎn)攻擊對(duì)象。

DNS的這些安全漏洞，致使它面臨的威脅主要集中在兩大方向：拒絕服務(wù)攻擊，數(shù)據(jù)欺騙攻擊。

拒絕服務(wù)攻擊（DOS：Denial Of Service），是一種使合法的用戶不能正常接入系統(tǒng)或者網(wǎng)絡(luò)資源，或者使得系統(tǒng)或者網(wǎng)絡(luò)自身無法正常提供服務(wù)的攻擊手段。分布式拒絕服務(wù)攻擊（Distributed Denial Of Service：DDoS）是大規(guī)模分布式實(shí)現(xiàn)DOS的一種方式。DDoS攻擊可能會(huì)涉及到成千上萬臺(tái)設(shè)備，通常來自于僵尸網(wǎng)絡(luò)，或者機(jī)器人網(wǎng)絡(luò)等。DNS協(xié)議是DDoS攻擊最常用的一種UDP協(xié)議，它幾乎具備發(fā)動(dòng)DDoS攻擊所需要的所有條件，因此也最為DDoS攻擊者青睞。數(shù)據(jù)欺騙攻擊通常指以某種方式篡改 DNS數(shù)據(jù)，獲取域名的解析控制權(quán)，以達(dá)到欺騙接收者的目的，包括緩存投毒，DNS劫持等方式，下面討論幾種最為典型的DNS威脅。

2.1 DNS反射放大攻擊

DNS反射攻擊是最常見的一種利用DNS的攻擊方式，實(shí)現(xiàn)這種攻擊需要具備兩個(gè)條件，一個(gè)是攻擊者要偽造 DNS查詢的源地址，第二是有開放的遞歸解析服務(wù)器。DNS是典型的 UDP傳輸協(xié)議，源地址可以輕易偽造，并且缺乏源地址真實(shí)性的認(rèn)證機(jī)制，現(xiàn)實(shí)中也存在大量的開放的遞歸解析服務(wù)器，恰好滿足上述兩個(gè)條件。攻擊者通過向開放的遞歸解析服務(wù)器發(fā)送大量的偽造源地址的DNS查詢請(qǐng)求，以此將DNS響應(yīng)流量導(dǎo)向攻擊者偽造的源地址，也就是受害者，當(dāng)響應(yīng)流量足夠大時(shí)，這種攻擊會(huì)對(duì)受害者造成拒絕服務(wù)攻擊，致使受害者系統(tǒng)癱瘓。

反射放大攻擊是在反射攻擊的基礎(chǔ)上再增加一個(gè)條件：查詢響應(yīng)流量成倍的大于查詢請(qǐng)求流量，DNS正好具備這個(gè)能力，例如，可以通過查詢僅有 64字節(jié)的“ANY”資源記錄，就可以得到512字節(jié)的查詢響應(yīng)，以此來實(shí)現(xiàn)響應(yīng)流量放大，典型的反射放大攻擊如圖3所示。

圖3 DNS反射放大攻擊

近年來，利用 DNS實(shí)現(xiàn)反射放大攻擊案例比比皆是，2013年，反垃圾郵件組織Spamhaus遭遇了一次峰值為300Gbps的DNS反射放大攻擊[4]，攻擊者發(fā)出長(zhǎng)為36字節(jié)的DNS查詢數(shù)據(jù)包，卻得到了長(zhǎng)為3000字節(jié)的響應(yīng)數(shù)據(jù)包，直接導(dǎo)致大量合法用戶不能訪問該機(jī)構(gòu)網(wǎng)站，這也是最具影響力的一次反射放大攻擊。另據(jù)Arbor Networks記錄，2016年里約奧運(yùn)會(huì)期間，攻擊者利用DNS及其他協(xié)議，針對(duì)巴西政府發(fā)動(dòng)了峰值為540Gbps的DDoS攻擊[5]。

2.2 隨機(jī)子域/非存在域名攻擊

隨機(jī)子域（Random Subdomain）攻擊，在這種攻擊中，攻擊者通過向開放遞歸解析服務(wù)器查詢合法域名的隨機(jī)子域名或者根本就不存在的子域名來實(shí)現(xiàn)攻擊，例如，查詢xxxxx.google.com，這種域名不會(huì)得到正確的響應(yīng)，攻擊者可以通過控制僵尸網(wǎng)絡(luò)來自動(dòng)大量發(fā)送這些查詢請(qǐng)求，以此來耗盡 DNS權(quán)威服務(wù)器的帶寬和資源，造成這些權(quán)威服務(wù)器無法向合法用戶提供正常的服務(wù)。

非存在域名（NXDomain Name），是指由攻擊者設(shè)置和控制的一些解析非常緩慢或者根本得不到正確解析的域名。非存在域名攻擊類似于隨機(jī)子域名攻擊，攻擊者向開放遞歸服務(wù)器發(fā)送大量非存在域名的查詢請(qǐng)求，但這些域名解析緩慢或者不能解析，以此來讓 DNS解析服務(wù)器一直在等待解析響應(yīng)，以達(dá)到消耗解析服務(wù)器資源，實(shí)現(xiàn)拒絕服務(wù)攻擊的目的。

2.3 DNS緩存投毒攻擊

緩存投毒是最流行的 DNS欺騙方式，盡管緩存投毒的攻擊理論早已存在[6]，但由于實(shí)施困難，成功率低并沒有得到足夠重視，2008年，Dan Kaminsky在Black Hat的演講讓緩存投毒攻擊成為一種切實(shí)可行的攻擊方式[7]。

緩存投毒攻擊是指攻擊者將“污染”的緩存記錄插入到正常的DNS名稱服務(wù)器的緩存記錄中，所謂污染的緩存記錄指DNS解析服務(wù)器中域名所對(duì)應(yīng)的 IP地址不是真實(shí)的地址，而是由攻擊者篡改的地址，這些地址通常對(duì)應(yīng)著由攻擊者控制的服務(wù)器，下面詳述緩存投毒實(shí)現(xiàn)方式：

用戶A向解析器R請(qǐng)求查詢xxxxx.google.com的IP地址，R中并不會(huì)緩存 xxxxx.google.com的資源記錄，R將會(huì)轉(zhuǎn)向google.com的權(quán)威名稱服務(wù)器，假設(shè) R合法解析得來的地址是IP1，但是攻擊者會(huì)在該響應(yīng)到達(dá)前，偽造大量解析地址為 IP2響應(yīng)包發(fā)送給R（其中要在TTL內(nèi)成功猜測(cè)transaction ID，若猜測(cè)不成功，則更換隨機(jī)域名重新發(fā)動(dòng)，詳見文獻(xiàn)[8]），而IP2是攻擊者控制的服務(wù)器，通常為釣魚網(wǎng)站等，由于R很難檢測(cè)來源響應(yīng)的真實(shí)性，并且根據(jù) DNS接收策略，當(dāng)接收到第一個(gè)響應(yīng)包后會(huì)丟棄隨后的響應(yīng)，隨后 R會(huì)將該條記錄存入到自身緩存中，這樣就完成了緩存投毒的過程。當(dāng)其他合法用戶查詢時(shí)，R由于緩存中已經(jīng)存入IP2且尚未過期，會(huì)直接將IP2響應(yīng)給用戶，致使用戶訪問攻擊者控制的站點(diǎn)，結(jié)合社會(huì)工程學(xué)，攻擊者利用偽造的網(wǎng)站頁面誘使受害者下載病毒和木馬，以此達(dá)到控制受害者機(jī)器，盜取受害者敏感信息的目的。

緩存投毒攻擊是最危險(xiǎn)的一種 DNS攻擊方式，利用它可以實(shí)現(xiàn)中間人攻擊和拒絕服務(wù)攻擊，導(dǎo)致用戶隱私泄露和財(cái)產(chǎn)損失，使合法用戶不能正常接入站點(diǎn)，站點(diǎn)不能為用戶提供正常服務(wù)。

2.4 DNS劫持

DNS劫持是另外一種常見的DNS欺騙攻擊，從攻擊結(jié)果來看，DNS劫持（重定向）和緩存投毒很相似，攻擊想要實(shí)現(xiàn)的目的都是控制特定域名的解析記錄，導(dǎo)致域名對(duì)應(yīng)的 IP地址被篡改為由攻擊者控制的假的站點(diǎn)。攻擊者通常會(huì)通過兩種方式實(shí)現(xiàn)DNS劫持，一種是直接攻擊域名注冊(cè)商或者域名站點(diǎn)獲取控制域名的賬戶口令，這樣可以修改域名對(duì)應(yīng)的 IP地址，另外一種方式是攻擊權(quán)威名稱服務(wù)器，直接修改區(qū)域文件內(nèi)的資源記錄。

對(duì)于企業(yè)和機(jī)構(gòu)客戶而言，遭遇 DNS劫持是非常嚴(yán)重的問題，它會(huì)導(dǎo)致機(jī)構(gòu)失去對(duì)域名的控制，一旦攻擊實(shí)現(xiàn)，機(jī)構(gòu)的站點(diǎn)將不能訪問，或者用戶可能會(huì)訪問到偽造的站點(diǎn)。當(dāng)用戶接入如支付寶，銀行等合法站點(diǎn)時(shí)遭遇域名劫持，用戶將面臨個(gè)人賬戶和敏感信息泄露，財(cái)產(chǎn)損失等風(fēng)險(xiǎn)。

2.5 DNS隧道

DNS查詢請(qǐng)求通常被視為安全的數(shù)據(jù)類型，防火墻和入侵檢測(cè)設(shè)備一般不會(huì)攔截。DNS隧道正是利用這一特點(diǎn)，將其他的數(shù)據(jù)和協(xié)議（如 shellcode）編碼為 DNS查詢請(qǐng)求，以此方式來躲避防火墻和入侵檢測(cè)設(shè)備。

DNS隧道最初被設(shè)計(jì)用來繞過WIFI Web認(rèn)證，但是，在攻擊者眼里，DNS隧道被視為實(shí)現(xiàn)遠(yuǎn)程控制的一種方式，也就是說，通過DNS隧道，攻擊者可以通過DNS服務(wù)器去遠(yuǎn)程執(zhí)行命令和控制數(shù)據(jù)傳輸。

攻擊者想要實(shí)現(xiàn) DNS隧道，必須控制一個(gè)內(nèi)網(wǎng)的客戶端，客戶端不需要連接外網(wǎng)，能夠向內(nèi)部的 DNS服務(wù)器發(fā)送和接收外部站點(diǎn)的 DNS請(qǐng)求和響應(yīng)即可。由于防火墻和入侵檢測(cè)設(shè)備很少攔截 DNS查詢和響應(yīng)，因此，被控客戶端可以將數(shù)據(jù)編碼為DNS請(qǐng)求，通過DNS服務(wù)器發(fā)送給攻擊者，攻擊者同樣可以將控制命令編碼為 DNS響應(yīng)發(fā)送給被控客戶端，這樣就可以在被控客戶端和攻擊者之間安全傳輸命令和數(shù)據(jù)[9，10]。多種工具可以輕易實(shí)現(xiàn)DNS隧道，比如DNSCat[11]，Iodine，DNS2TCP等。

3 防御及緩解措施

針對(duì) DNS所暴露的問題，相關(guān)研究人員已提出很多安全建議，工業(yè)界也引入了大量的對(duì)抗 DNS攻擊的安全產(chǎn)品，但所采用的防御和緩解措施大致有以下幾種。

3.1 DNSSEC

DNSSEC （Domain Name System Security Extensions，DNS 安全擴(kuò)展）[12]，目前來看，最有希望解決DNS安全問題的安全措施就是DNSSEC。簡(jiǎn)而言之，DNSSEC依賴于數(shù)字簽名和公鑰系統(tǒng)去保護(hù) DNS數(shù)據(jù)的可信性和完整性。權(quán)威名稱服務(wù)器用自身的私鑰來簽名資源記錄，然后解析服務(wù)器用權(quán)威名稱服務(wù)器的公鑰來認(rèn)證來自權(quán)威名稱服務(wù)器的數(shù)據(jù)，如果認(rèn)證成功，則表明接收到的數(shù)據(jù)確實(shí)來自權(quán)威名稱服務(wù)器，則解析服務(wù)器接收數(shù)據(jù)，如果認(rèn)證失敗，則表明接收到的數(shù)據(jù)很可能是偽造的，則解析服務(wù)器拋棄數(shù)據(jù)。文獻(xiàn)[13]提供了DNSSEC的具體的相關(guān)的概念和安全特色。

DNSSEC確實(shí)也存在一些問題，由于認(rèn)證過程涉及到公鑰運(yùn)算的加解密過程，它會(huì)增加系統(tǒng)的消耗，延長(zhǎng) DNS解析時(shí)間，并且要完成認(rèn)證的話，需要部署從根域名服務(wù)器到站點(diǎn)域名服務(wù)器的信任鏈，正因如此，很多機(jī)構(gòu)不愿部署DNSSEC。此外，由于DNSSEC的響應(yīng)包放大倍數(shù)顯著大于正常DNS響應(yīng)包，如果部署不當(dāng)，恰好為放大攻擊所濫用[14]。

3.2 Anycast

Anycast（任撥）[15]是一種網(wǎng)絡(luò)路由方式，通過部署Anycast，提供相同服務(wù)的一組服務(wù)器可以使用相同的 IP地址， 客戶端的請(qǐng)求數(shù)據(jù)將會(huì)被轉(zhuǎn)發(fā)到這組服務(wù)器中路由拓?fù)浣Y(jié)構(gòu)最近的一臺(tái)主機(jī)上。不難發(fā)現(xiàn)，Anycast可以用來抵抗DDoS攻擊[16]，當(dāng)攻擊者通過僵尸網(wǎng)絡(luò)發(fā)動(dòng)DDoS攻擊時(shí)候，由于僵尸網(wǎng)絡(luò)的主機(jī)具有不同的 IP地址和地理位置，這些來自僵尸網(wǎng)絡(luò)的流量會(huì)被發(fā)送到的不同的主機(jī)，正因如此，幾乎所有的根域名服務(wù)器都已經(jīng)部署了 Anycast，這種方式可以理解為用分布式防御對(duì)抗分布式攻擊。

3.3 響應(yīng)率限制

響應(yīng)率限制是指允許權(quán)威服務(wù)器可以統(tǒng)計(jì)自身所發(fā)送的來源于相同的DNS查詢所對(duì)應(yīng)的DNS響應(yīng)的頻次，權(quán)威服務(wù)器可以設(shè)置一個(gè)發(fā)送次數(shù)的閾值，規(guī)定在某一段時(shí)間內(nèi)，若發(fā)送響應(yīng)的頻次超過設(shè)定的閾值，權(quán)威名稱服務(wù)器會(huì)停止發(fā)送響應(yīng)，并且持續(xù)一段時(shí)間，若在這段時(shí)間內(nèi)，權(quán)威名稱服務(wù)器沒有收到同樣頻次的查詢，則取消限制。因此，權(quán)威名稱服務(wù)器將不會(huì)發(fā)送高于這個(gè)閾值的DNS響應(yīng)，這樣將有效保護(hù)DNS權(quán)威名稱服務(wù)器原理 DDoS攻擊。響應(yīng)率限制可以緩解DNS 放大攻擊的影響，但是同樣存在幾點(diǎn)問題，它僅僅對(duì)于權(quán)威名稱服務(wù)器有效，對(duì)于公開遞歸服務(wù)器無效，攻擊者也可以通過發(fā)送一組不同的查詢而不是一個(gè)查詢發(fā)送多次來繞過，另外，響應(yīng)率限制也可能會(huì)影響合法用法使用。

3.4 設(shè)置遞歸服務(wù)器查詢權(quán)限

利用DNS來實(shí)現(xiàn)DDoS攻擊之所以能夠輕易成功的關(guān)鍵原因之一是，大部分的開放式遞歸服務(wù)器可以讓任何人執(zhí)行 DNS查詢請(qǐng)求，而一個(gè)安全的 DNS遞歸服務(wù)器不應(yīng)該向任何人開放查詢權(quán)限，DNS服務(wù)器管理者應(yīng)當(dāng)控制接入權(quán)限，保證授權(quán)的用戶可以執(zhí)行DNS查詢。

4 結(jié)語

DNS是互聯(lián)網(wǎng)正常運(yùn)轉(zhuǎn)的基石，但是它的自身安全被大部分用戶忽視。近年來，由于它先天的設(shè)計(jì)缺陷，DNS被攻擊者利用發(fā)動(dòng)各種類型攻擊。本文研究了 DNS面臨的典型威脅，討論了這些威脅的實(shí)現(xiàn)原理和方式，并且給出了一些有效的防御和緩解措施。

[1] Mockapetris P．V．Domain names： Concepts and Facilities RFC1034[S],1987．

[2] Mockapetris P．V．Domain names： Implementation and Specification RFC1035[S],1987．

[3] Liu Cricket and Albitz Paul．DNS and BIND[M]． 5th． CA．O'Reilly Media Inc,2006．

[4] Matthew Prince．The DDoS That Knocked Spamhaus Offline．2013．https：//blog．cloudflare．com/the-ddos-that-knocke d-spamhaus-offline-and-ho/．

[5] Cimpanu Catalin．ddos attacks during rio olympics peaked at 540 gbps,2016．

[6] Jiang Jian,Liang Jinjin,Li Kang,Li Jun,Duan Haixinand Wu Jianping．Ghost Domain Names： Revoked Yet Still Resolvable [C]//Network and Distributed System Security Symposium，2012．

[7] Tom Olzak．DNS Cache Poisoning： Definition and Prevention，2006．

[8] Kaminsky D．Black ops 2008-it’s the end of the cache as we know it [C]//BlackHat， 2008．

[9] Sooel Son and Vitaly Shmatikov．The Hitchhiker’s Guide to DNS Cache Poisoning [C]//Security and Privacy in Communication Networks - Iternational ICST Conference，SECURECOMM 2010， Singapore， September 7-9， 2010．Proceedings，2010．

[10] Cian Lynch,Dimiter Andonov and Claudiu Teodorescu．MULTIGRAIN-Point of Sale Attackers Make an Unhealthy Addition to the Pantry．2016．https：// www．fireeye．com/blog/threat-research/2016/04/multigrain_pointo．html．

[11] E．Skoudis．The six most dangerous new attack techniques and what’s coming next 2012． https：//blogs．sans．org/pentesting/files/2012/03/ RSA-2012-EXP-108-Skoudis-Ullrich．pdf．

[12] Bowes Ron．Weaponizing dnscat with shellcode and Metasploit．2010．https：//blog．skullsecurity．org/2010/weaponizingdnscat-with-shellcode-and-metasploit．

[13] Giuseppe Ateniese and Stefan Mangard．A new approach to DNS security (DNSSEC) [C]//In Proceedings of the 8th acm conference on Computer and Communications Security,2001．

[14] NIST．DNS Security Introduction and Requirem ents RFC 4033[S],2005．

[15] Rijswijk-Deij Roland Van,Sperotto Anna and Pras Aiko．DNSSEC and its potential for DDoS attacks：a comprehensive measurement study [C]//Conference on Internet Measurement Conference,ACM,2014．

[16] Abley J,Canada Afilias and Lindqvist K．Operation of anycast services [J]．RFC 4786,2006．

[17] Giovane C． M． Moura,Ricardo O．Schmidt De,John Heidemann,Wouter B．Vries De,Moritz Müller,Lan Wei and Cristian Hesselman．Anycast vs．DDoS：Evaluating the November 2015 Root DNS Event,2016．