亚洲狠狠干,亚洲国产福利精品一区二区,国产八区,激情文学亚洲色图

一種保證安全和隱私的dns端到端解析方法

文檔序號:9600856閱讀:380來源:國知局
一種保證安全和隱私的dns端到端解析方法
【技術領域】
[0001]本發(fā)明屬于DNS安全防范技術領域,尤其涉及一種保證安全和隱私的DNS端到端解析方法。
【背景技術】
[0002]DNS為互聯(lián)網(wǎng)提供重要的服務,其本質是建立了人的名字世界和底層的二進制協(xié)議地址世界之間的橋梁。DNS解析框架是一個使用UDP協(xié)議并通過地理分布的具有緩存功能的遞歸解析器來實現(xiàn)。其基本流程如圖1所示:用戶發(fā)出一個域名的DNS請求到本地ISP的遞歸解析器(Recursive Resolver) 0如果本地的遞歸服務器緩存了這個DNS請求條目,則遞歸服務器直接向用戶返回DNS相應消息。如果本地的遞歸服務器沒有緩存這個DNS請求消息,則本地的遞歸服務器從根服務器開始,根據(jù)所返回的信息,一級一級地遞歸查詢所請求的域名。最終查找到所要查詢的DNS信息。遞歸服務器將返回的DNS查詢結果存儲到自己的緩存中,同時將結果返回給用戶。這樣一個完整的DNS查詢過程就完成了。
[0003]但是在這個過程中存在著許多的安全和隱私方面的問題。首先從用戶到遞歸服務器這一段。由于DNS查詢中包含著用戶的地址和期望查詢的內容。竊聽者就很容易地竊聽到這些信息。其次,存在一些網(wǎng)絡設備基于經(jīng)濟上的原因,蓄意地阻斷、捕獲或修改DNS的流量,如一些旅館的WiFi系統(tǒng)、用戶的ISP等。由于DNS通過UDP傳輸?shù)臒o狀態(tài)特性,用戶無法辨別這些信息的真?zhèn)?。在遞歸解析器到名字服務器這一段中,由于DNS請求是通過遞歸服務器發(fā)送的,所以監(jiān)聽者無法獲知DNS請求真正來源于哪一個用戶,所以就不存在隱私泄露問題。但是注入攻擊(如Kaminsky攻擊)會向遞歸服務器緩存中注入虛假的域名信息,使得用戶從遞歸服務器緩存中獲得的DNS數(shù)據(jù)不是他真正需要的,用戶可能訪問攻擊者的地址。
[0004]針對DNS的隱私問題提出了許多解決方案,如DNS over TCP和DNS over HTTP⑶,但這些方案的缺點是客戶端和解析側之間需要建立TCP連接,TCP連接的建立需要較長的時延和維護狀態(tài)信息的開銷。特別是從遞歸解析側到權威名字服務器這一側,由于較長的RTT值,帶來的時延更顯著。DNSSEC協(xié)議通過加密機制能夠保證用戶得到的數(shù)據(jù)的真實性和完整性,避免注入攻擊帶來的安全問題。但是DNSSEC消息需要更強的計算能力來處理開銷,這對普通的終端設備,特別是如一些智能手機設備是接受不了的。

【發(fā)明內容】

[0005]為了解決傳統(tǒng)的DNS協(xié)議通過UDP傳輸DNS消息時所存在的安全和隱私泄露的問題,本發(fā)明提出了一種保證安全和隱私的DNS端到端解析方法,包括:
[0006]步驟1、首先在客戶端操作系統(tǒng)的配置文件中配置遞歸服務器的地址;
[0007]步驟2、當客戶端發(fā)送DNS查詢消息后,DNS消息將首先被發(fā)送到本機的127.X.X.X的地址上,客戶端代理進程接收到DNS查詢消息;
[0008]步驟3、客戶端代理負責同遞歸服務器的代理建立HTTP或HTTPS連接;
[0009]步驟4、如果遞歸服務器的代理不支持安全機制,則使用遞歸服務器的80端口建立TCP連接;如果服務器支持HTTP或HTTPS,則使用服務器的443端口建立TCP連接;
[0010]步驟5、客戶端采用POST的交互方式向遞歸服務器發(fā)送數(shù)據(jù),DNS消息以二進制內容通過HTTP或HTTPS發(fā)送到遞歸服務器代理;
[0011]步驟6、當遞歸服務器代理接收到DNS消息后,會將DNS消息轉交給遞歸服務器的53 端口;
[0012]步驟7、當從遞歸服務器獲取DNS的響應消息后,采用跟DNS請求消息相反的過程將DNS響應消息發(fā)送到客戶端;
[0013]步驟8、當遞歸服務器的緩存中不存在DNS查詢的信息時,遞歸服務器向權威服務器發(fā)送DNS請求;遞歸服務器在DNS查詢中設置“D0”標記位,表示支持DNSSEC協(xié)議。
[0014]所述遞歸服務器代理通過Ngnix或Apache配置HTTP或HTTPS服務器。
[0015]所述遞歸服務器通過BIND或PowerDNS或Unbound的開源DNS軟件搭建。
[0016]所述遞歸服務器與客戶端之間設置UDP或TCP的DNS請求機制,用于HTTP或HTTPS的客戶端代理或遞歸服務器代理因處理能力或各種故障導致不工作時的備用保障機制。
[0017]本發(fā)明的有益效果在于:能夠提供完整的端到端的DNS查詢方案,在解析過程中有針對性的解決的DNS查詢的安全和隱私保護問題。在客戶端和遞歸服務器之間為避免隱私泄露和DNS劫持等問題,采用HTTP (S)傳輸DNS消息,TLS (Transport Layer Security)能夠進一步保護DNS消息的隱私性。且可以利用HTTP(S)已有的優(yōu)化方案來改善TCP的性能和傳輸性能。在遞歸服務器和權威服務器中引入DNSSEC機制能夠有效避免DNS消息的注入攻擊,保證了 DNS信息的完整性和真實性。不同于之前的方案(如基于JS0N編碼的方案),本發(fā)明提出通過傳輸二進制碼的形式直接傳輸DNS消息。同其它的方案相比,本發(fā)明的效率更高,實現(xiàn)起來更加簡單。
【附圖說明】
[0018]圖1為DNS解析流程圖;
[0019]圖2為本發(fā)明的端到端的DNS解析結構圖;
[0020]圖3為本發(fā)明的基于HTTP或HTTPS的DNS實現(xiàn)機制示意圖。
【具體實施方式】
[0021]下面結合附圖,對實施例作詳細說明。
[0022]如圖2所示,本發(fā)明提出在用戶到遞歸服務器通過HTTP(S)協(xié)議來保證安全和隱私;在從遞歸服務器到權威名字服務器通過DNSSEC來保證數(shù)據(jù)的安全。以一個域名www.example, com的A類型查詢?yōu)槔?,說明DNS端到端的解析方案的工作流程。
[0023]客戶端向127.X.X.X的地址上發(fā)送域名為www.example, com的A類型的查詢請求。本地的客戶代理接收到DNS消息后,同遞歸服務器的代理建立HTTP或HTTPS的連接。連接建立好后,可以通過HTTP (S)的PUSH方式將DNS消息以二進制碼的形式發(fā)送到遞歸服務器代理。如果通過HTTP協(xié)議發(fā)送,則權威服務器代理的端口是80 ;如果是通過HTTPS協(xié)議發(fā)送,則權威服務器代理的端口是443。遞歸服務器代理接收到DNS消息后,將DNS消息內容轉交給遞歸服務器的53端口。
[0024]遞歸服務器接受到DNS消息,按照正常的遞歸服務器流程處理該DNS消息。首先它查詢遞歸服務的本地緩存,如果本地緩存中存在客戶請求的DNS內容,則不必再查詢權威名字服務器。當本地緩存中不存在用戶請求的DNS內容時,遞歸服務器設置“D0”位,并向權威服務器發(fā)送DNS遞歸請求。權威名字服務器的響應消息中包含權威的DNS資源記錄和DNSSEC相關的資源記錄。當這些資源記錄信息發(fā)送到遞歸服務器后,遞歸服務器負責基于DNSSEC的消息驗證機制。如果通過DNSSEC驗證,則證明得到的數(shù)據(jù)滿足真實性和完整性。然后遞歸服務器負責將數(shù)據(jù)傳輸?shù)紿TTP (S)遞歸服務器代理,再通過HTTP (S)將數(shù)據(jù)傳送到客戶端。
[0025]此實施例僅為本發(fā)明較佳的【具體實施方式】,但本發(fā)明的保護范圍并不局限于此,任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內,可輕易想到的變化或替換,都應涵蓋在本發(fā)明的保護范圍之內。因此,本發(fā)明的保護范圍應該以權利要求的保護范圍為準。
【主權項】
1.一種保證安全和隱私的DNS端到端解析方法,其特征在于,包括: 步驟1、首先在客戶端操作系統(tǒng)的配置文件中配置遞歸服務器的地址; 步驟2、當客戶端發(fā)送DNS查詢消息后,DNS消息將首先被發(fā)送到本機的127.X.X.X的地址上,客戶端代理進程接收到DNS查詢消息; 步驟3、客戶端代理負責同遞歸服務器的代理建立HTTP或HTTPS連接; 步驟4、如果遞歸服務器的代理不支持安全機制,則使用遞歸服務器的80端口建立TCP連接;如果服務器支持HTTP或HTTPS,則使用服務器的443端口建立TCP連接; 步驟5、客戶端采用POST的交互方式向遞歸服務器發(fā)送數(shù)據(jù),DNS消息以二進制內容通過HTTP或HTTPS發(fā)送到遞歸服務器代理; 步驟6、當遞歸服務器代理接收到DNS消息后,會將DNS消息轉交給遞歸服務器的53端P ; 步驟7、當從遞歸服務器獲取DNS的響應消息后,采用跟DNS請求消息相反的過程將DNS響應消息發(fā)送到客戶端; 步驟8、當遞歸服務器的緩存中不存在DNS查詢的信息時,遞歸服務器向權威服務器發(fā)送DNS請求;遞歸服務器在DNS查詢中設置“DO”標記位,表示支持DNSSEC協(xié)議。2.根據(jù)權利要求1所述方法,其特征在于,所述遞歸服務器代理通過Ngnix或Apache配置HTTP或HTTPS服務器。3.根據(jù)權利要求1所述方法,其特征在于,所述遞歸服務器通過BIND或PowerDNS或Unbound的開源DNS軟件搭建。4.根據(jù)權利要求1所述方法,其特征在于,所述遞歸服務器與客戶端之間設置UDP或TCP的DNS請求機制,用于HTTP或HTTPS的客戶端代理或遞歸服務器代理因處理能力或各種故障導致不工作時的備用保障機制。
【專利摘要】本發(fā)明屬于DNS安全防范技術領域,尤其涉及一種保證安全和隱私的DNS端到端解析方法,包括:客戶端操作系統(tǒng)的配置文件中配置遞歸服務器的地址;客戶端發(fā)送DNS查詢消息到本機的127.X.X.X的地址上,客戶端代理進程接收并同遞歸服務器的代理建立HTTP或HTTPS連接;客戶端采用POST的交互方式向遞歸服務器發(fā)送數(shù)據(jù),DNS消息以二進制內容通過HTTP或HTTPS發(fā)送到遞歸服務器代理;當從遞歸服務器獲取DNS的響應消息后,采用跟DNS請求消息相反的過程將DNS響應消息發(fā)送到客戶端;當遞歸服務器的緩存中不存在DNS查詢的信息時,遞歸服務器通過DNSSEC向權威服務器發(fā)送DNS請求。
【IPC分類】H04L29/06
【公開號】CN105357212
【申請?zhí)枴緾N201510819260
【發(fā)明人】宋林健, 劉 東, 萬潤夏, 李震, 宋松, 余冬, 王愛民, 潘居臣, 龔道彪
【申請人】北京天地互連信息技術有限公司, 中國石油天然氣股份有限公司華北油田分公司
【公開日】2016年2月24日
【申請日】2015年11月23日
網(wǎng)友詢問留言 已有0條留言
  • 還沒有人留言評論。精彩留言會獲得點贊!
1