本發(fā)明涉及DNS安全領域，尤其涉及一種DNSSEC否定應答的響應及處理方法。

背景技術(shù)：

DNSSEC是Domain Name System Security Extensions的縮寫，是DNS系統(tǒng)的一種安全擴展，是由IETF提供的一系列DNS安全認證的機制(可參考RFC2535)。它提供一種可以驗證應答信息真實性和完整性的機制，利用密碼技術(shù)，使得域名解析服務器可以驗證它所收到的應答(包括域名不存在的應答)是否來自于真實的服務器，或者是否在傳輸過程中被篡改過。DNSSEC目前已經(jīng)部署在根、多個頂級域和國家頂級域。通過DNSSEC的部署，可以增強對DNS域名服務器的身份認證，進而幫助防止DNS緩存污染等攻擊。DNSSEC給解析服務器提供了防止上當受騙的武器，是實現(xiàn)DNS安全的重要一步和必要組成部分。

為了驗證域名不存在的應答，DNSSEC引入了一種類型為NSEC3的資源記錄(可參考RFC5155)。NSEC3類型的資源記錄的owner為域名格式，其內(nèi)容為域名經(jīng)過數(shù)次SHA1加密之后通過Base32編碼轉(zhuǎn)換生成的一串長度為32字節(jié)的字符串和區(qū)名的組合。為了證明域名的不存在性，通常在回復報文中會包含最多3條的NSEC3資源記錄和他們對應資源記錄簽名(RRSIG)，為了回復對應的NSEC3記錄，DNS權(quán)威服務器在一般的實現(xiàn)方式下會計算多次SHA1算法加密和base32編碼轉(zhuǎn)換，這些計算極大地降低了DNS權(quán)威服務器對于DNSSEC否定應答的響應速度，目前市面上常用的DNS軟件通常都有此問題。由于在這一種特殊情況下DNS權(quán)威服務器的處理性能急劇下降，致使黑客能夠更加有針對性地對整個DNS系統(tǒng)進行攻擊，從而使部署實施DNSSEC的DNS系統(tǒng)變的更加脆弱。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的在于：提高DNS權(quán)威服務器對于DNSSEC否定應答的響應速度；降低針對DNSSEC否定應答的分布式拒絕服務DDOS(Distributed Denial of Service)攻擊的風險。

本發(fā)明提出了一種DNSSEC否定應答的響應方法，其包括以下步驟：

步驟A1、權(quán)威DNS服務器通過區(qū)文件形式加載DNS數(shù)據(jù)；

步驟A3、權(quán)威DNS服務器對加載的所有域名進行SHA1加密和base32編碼計算并保存計算結(jié)果；

步驟A5、權(quán)威DNS服務器接收DNS查詢。

其中，所述步驟A5具體包括：

步驟A51、判斷所述DNS查詢是否請求DNSSEC應答；

步驟A53、如果是，則由所述權(quán)威DNS服務器處理所述DNS查詢。

其中，所述步驟A53具體包括：

步驟A531、權(quán)威DNS服務器判斷是否針對該DNS查詢返回DNSSEC否定應答；

步驟A533、如果是，則根據(jù)步驟A3中的計算結(jié)果查找NSEC3記錄，并構(gòu)成DNSSEC否定應答消息；

步驟A535、權(quán)威DNS服務器返回包含DNSSEC否定應答消息的DNS響應報文。

本發(fā)明還提出了一種基于DNSSEC否定應答的響應方法的處理方法，其包括以下步驟：

步驟B1、設定DDOS檢測閾值；

步驟B3、計算接收的DNSSEC否定應答查詢數(shù)；

步驟B5、根據(jù)查詢數(shù)與所述閾值的比較，判斷是否存在針對DNSSEC否定應答的DDOS攻擊。

其中，所述步驟B1中DDOS檢測閾值＝帶寬/包含DNSSEC否定應答消息的DNS響應報文的平均長度；所述包含DNSSEC否定應答消息的DNS響應報文為步驟A535中DNS服務器返回的DNS響應報文。

其中，所述步驟B5具體包括如果接收的DNSSEC否定應答查詢數(shù)大于檢測閾值，則表示存在針對DNSSEC否定應答的DDOS攻擊。

本發(fā)明的優(yōu)點在于：由于不會在查詢處理的過程中進行額外的計算，DNSSEC否定應答的響應速度相比一般查詢不會有明顯的下降，并根據(jù)DNSSEC否定應答報文長度相比正常應答報文大幅增加的特點，提供了針對DNSSEC否定應答查詢的DDOS攻擊檢測方法。

附圖說明

通過閱讀下文優(yōu)選實施方式的詳細描述，各種其他的優(yōu)點和益處對于本領域普通技術(shù)人員將變得清楚明了。附圖僅用于示出優(yōu)選實施方式的目的，而并不認為是對本發(fā)明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中：

附圖1示出了現(xiàn)有技術(shù)的處理DNSSEC否定應答的流程圖；

附圖2示出了正常查詢應答速度與DNSSEC否定應答的響應速度對比；

附圖3示出了根據(jù)本發(fā)明實施例的DNSSEC否定應答的流程圖。

具體實施方式

下面將參照附圖更詳細地描述本公開的示例性實施方式。雖然附圖中顯示了本公開的示例性實施方式，然而應當理解，可以以各種形式實現(xiàn)本公開而不應被這里闡述的實施方式所限制。相反，提供這些實施方式是為了能夠更透徹地理解本公開，并且能夠?qū)⒈竟_的范圍完整的傳達給本領域的技術(shù)人員。

如圖1所示為現(xiàn)有技術(shù)中處理DNSSEC否定應答的流程圖，流程如下：

步驟1、權(quán)威DNS服務器通過區(qū)文件形式加載DNS數(shù)據(jù)；

步驟2、權(quán)威DNS服務器接收DNS查詢；

如果權(quán)威DNS服務器對DNNSEC否定應答的DNS查詢處理，則進行如下步驟：

判斷DNS查詢是否請求DNSSEC應答；如果是，則權(quán)威DNS服務器處理DNS查詢；隨后判斷該DNS查詢權(quán)威DNS服務器是否需要返回DNSSEC否定應答；如果是，則對查詢域名進行SHA1加密和Base32編碼計算；然后根據(jù)計算結(jié)果查找NEC3記錄，組成DNSSEC否定應答；最后權(quán)威DNS服務器將應答結(jié)果組成DNS報文并回復。

基于現(xiàn)有的技術(shù)方案，為了查找對應的NSEC3資源記錄，每次的DNSSEC否定應答都需要計算數(shù)次的安全哈希算法SHA1(Secure Hash Algorithm)加密和Base32編碼運算。對于一次的DNS查詢來說，這些計算顯然是相當重的，這些計算會增加了單次查詢的處理時間，DNS服務器每秒鐘能處理的查詢數(shù)降低。

其中Base32這種數(shù)據(jù)編碼機制，主要用來把二進制數(shù)據(jù)編碼成可見的字符串，其編碼規(guī)則是：任意給定一個二進制數(shù)據(jù)，以5個位(bit)為一組進行切分(base64以6個位(bit)為一組)，對切分而成的每個組進行編碼得到1個可見字符。Base32編碼表字符集中的字符總數(shù)為25＝32個，這也是Base32名字的由來。

圖2展示了業(yè)界最常用的DNS軟件BIND9在DNSSEC否定應答的和正常查詢應答情況下的響應速度對比。從上圖可得出，對比正常查詢應答，DNSSEC否定應答的響應速度急劇下降。

為了克服以上弱點，本發(fā)明提出了一種新的方法。如圖3所示，一種針對DNSSEC否定應答的快速響應方法，其包括以下步驟：

步驟A1、權(quán)威DNS服務器通過區(qū)文件形式加載DNS數(shù)據(jù)；

步驟A3、權(quán)威DNS服務器對加載的所有域名進行SHA1加密和base32編碼計算并保存計算結(jié)果；

步驟A5、權(quán)威DNS服務器接收DNS查詢。

所述步驟A5具體包括：

步驟A51、判斷所述DNS查詢是否請求DNSSEC應答；

步驟A53、如果是，則由所述權(quán)威DNS服務器處理所述DNS查詢。

所述步驟A53具體包括：

步驟A531、權(quán)威DNS服務器判斷是否針對該DNS查詢返回DNSSEC否定應答；

步驟A533、如果是，則根據(jù)步驟A3中的計算結(jié)果查找NSEC3記錄，并構(gòu)成DNSSEC否定應答消息；

步驟A535、權(quán)威DNS服務器返回包含DNSSEC否定應答消息的DNS響應報文。

本發(fā)明申請?zhí)岢龅男碌募夹g(shù)方案和現(xiàn)有的技術(shù)方案最大的區(qū)別在于計算SHA1加密和base32編碼運算的時間，新的技術(shù)方案提出SHA1加密和base32編碼計算不再在查詢處理的過程中進行，而是在加載完DNS數(shù)據(jù)之后進行對應的預計算，這樣在查詢處理查找對應NSEC3資源記錄的時候和一般DNS查詢一樣只需獲取預計算的結(jié)果然后查找，并不會額外增加單次查詢處理的時間。同時通過數(shù)據(jù)結(jié)構(gòu)和算法的優(yōu)化，使得SHA1加密和base32編碼運算不會增加整個DNS數(shù)據(jù)加載時間。

其中，NESC3資源記錄(RR)為驗證DNS資源記錄的否定存在。NSEC3 RR具有與NSEC RR相同的功能，除了NSEC3使用加密的散列記錄名稱以防止區(qū)域中記錄名稱的枚舉之外。NSEC3記錄鏈接到區(qū)域中的下一個記錄名稱(以散列名稱排序的順序)并列出為了NSEC3記錄持有者名稱的第一標簽內(nèi)由散列值所覆蓋的名稱而存在的記錄類型。這些記錄可作為DNSSEC驗證的一部分而由解析器用于核實記錄名稱和類型的不存在性。NSEC3記錄含有下述數(shù)據(jù)元素：

散列算法：所用的密碼散列算法。

標志：“Opt-out”(指出委托是否被簽名)。

迭代：散列算法被應用了多少次。

加鹽(salt)：用于散列計算的加鹽值。

下一散列持有者名稱：區(qū)域中下一個記錄的名稱(以散列名稱排序的順序)。

記錄類型：為了NSEC3記錄持有者名稱的第一標簽內(nèi)由散列值覆蓋的名稱而存在的記錄類型。

由于DNSSEC否定應答包含多條NSEC3資源記錄和其簽名資源記錄，致使回應報文長度遠大于正常回應報文長度(最大為正常報文長度的13倍)，頻繁地回復DNSSEC否定應答會對網(wǎng)絡帶寬造成很大的壓力。黑客很容易針對此特性對DNS系統(tǒng)進行放大攻擊。因此本發(fā)明申請還提出一種針對DNSSEC否定應答的DDOS檢測方法，其具體原理為：根據(jù)計算設置一個DNSSEC否定應答查詢數(shù)閾值，閾值為帶寬/DNSSEC否定應答報文的平均長度，一旦接收的DNSSEC否定應答查詢數(shù)超過該閾值，則提示有可能有DNSSEC否定應答查詢的DDOS攻擊，一旦發(fā)現(xiàn)有此類DDOS攻擊，則可以通過前端DNS防護設備或者其他安全策略進行DDOS攻擊防護。

本發(fā)明還提出了一種針對DNSSEC否定應答的處理方法，其包括以下步驟：

步驟B1、設定DDOS檢測閾值；

步驟B3、計算接收的DNSSEC否定應答查詢數(shù)；

步驟B5、根據(jù)查詢數(shù)與所述閾值的比較，判斷是否存在針對DNSSEC否定應答的DDOS攻擊。

其中，所述步驟B1中DDOS檢測閾值＝帶寬/包含DNSSEC否定應答消息的DNS響應報文的平均長度；所述包含DNSSEC否定應答消息的DNS響應報文為步驟A535中DNS服務器返回的DNS響應報文。

其中，所述步驟B5具體包括如果接收的DNSSEC否定應答查詢數(shù)大于檢測閾值，則表示存在針對DNSSEC否定應答的DDOS攻擊。

以上所述，僅為本發(fā)明較佳的具體實施方式，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術(shù)領域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換，都應涵蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應所述以權(quán)利要求的保護范圍為準。