Dnssec籤名伺服器的製作方法

2023-05-28 21:38:36

專利名稱：Dnssec籤名伺服器的製作方法
DNSSEC籤名伺服器
背景技術：
域名系統(DNS)是網際網路基礎結構的一部分，其將人類可讀域名翻譯為通過網際網路建立TCP/IP通信所需的網際網路協議(IP)號碼。S卩，DNS允許用戶使用較容易記憶的域名(例如www. en. example, com)而不是數字IP位址(例如「 123. 4. 56. 78」)來訪問網站和其他資源，數字IP位址是軟體使用來與網際網路上的計算機進行通信的機器可讀地址。每個域名由一系列由點分隔開的字符串(標籤)組成。域名中最右端的標籤被認為是「頂級域名，，(TLD)。熟知的TLD例子是「 net」;「. org」等等。每個TLD支持直接在TLD的左側列出的第二級域，例如「WWW. example, com」中的「example」。姆個第二級域可支持多個直接位於在第二級域的左側的第三級域，例如「www. en. example, com」中的「en」。還可以存在附加級別域。例如具有附加域級別的域可以是「www. landscape, photos, example, com」。需要注意單個IP位址，例如分配給單個伺服器的ー個，可支持多個域名。即，不同 域名可解析到相同的伺服器，然後伺服器可基於請求的域名和/或附加非域信息來確定提供什麼內容。這有時被稱為虛擬主機(hosting)。附加非域信息可包括在包括域名的統ー資源標識符(「URI」)結構中。例如，「路徑」部分是由正斜槓(「/」)分隔開的一系列片段。該信息可以直接包括在域名的右側，例如「WWW. example, com/blog/today, htm」中的「blog」,並且可由伺服器或其他接收裝置用來識別和傳送特定內容或運行特定代碼。非域信息的其他示例可包括查詢和片段，其具體細節為本領域普通技術人員所理解並且不在此詳細討論。該信息的組合可包括在將用戶導航到相同頁面的其他部分或其他網頁的網頁超連結中。因此，從以上提供的各個示例可以看出，並如本領域技術人員所意識到的那樣，域，例如第二級域「example, com」，可包括多種具有不同地址和其他識別手段的不同網際網路可訪問信息。域名的實際註冊由公司執行，被稱作域名註冊商(registrar)( 「註冊商」)。註冊商向註冊局(registry)註冊域名。例如，終端用戶向註冊商提交域名用於註冊，並且提供該域名將要解析到的IP位址。註冊商與註冊局通信以創建註冊局資料庫記錄，註冊局資料庫記錄可用於將域名解析到終端用戶提供的IP位址，井指出註冊商的身份(通過它域名被註冊)。除非在註冊局域名註冊到期，典型地僅在註冊局的域名記錄中指定的註冊商可以修改或刪除有關域名的註冊局資料庫信息。終端用戶可通過遵循特定域轉移過程來轉換註冊商。註冊■商還可作為主機提供商(hosting provider),或者終端用戶可具有由獨立的第三方域主機服務寄存(host)的域。區域文件是描述被稱作DNS區域的DNS的一部分的文本文件。區域文件以資源記錄(RR)的形式組織並且包含定義域名和IP位址以及其他資源之間的映射的信息。區域文件的格式由標準定義，每行典型地定義單個資源記錄。行以域名開始，但是如果左側空白，則默認之前定義的域名。域名後面是生存時間(TTL)、類別(其對「網際網路」(「internet」)幾乎總是是「IN」並且很少被包括在內)、資源記錄的類型(A、MX、S0A等等)，其後跟隨類型特定數據，例如對於A記錄是IPv4地址。通過使用半冒號可包括注釋，以及通過使用圓括號可繼續行。還存在文件指導(file directive)，其用以美元符號開始的關鍵字標記。DNS通過為姆個域指定權威(authoritative)名稱伺服器來分布分配域名並將這些名稱映射到IP位址的責任。權威名稱伺服器被分配來負責它們的特定域，並且繼而可為它們的子域分配其他權威名稱伺服器。該機制通常幫助避免了單個中央註冊需要連續不斷地被查閱和更新。DNS解析過程允許用戶通過反向查找過程被指引到期望的域，從而用戶進入期望的域，並且DNS返回合適的IP號碼。在DNS解析過程期間，對給定域名的請求從解析器(例如樁解析器(stub resolver))路由至合適的伺服器(例如遞歸解析器)以檢索IP位址。為了改進效率、降低通過網際網路的DNS業務量以及增加終端用戶應用的性能，DNS支持DNS緩存伺服器(cache server)，其存儲DNS查詢結果達由正被考慮的域名記錄的生存時間(TTL)所確定的時間段。典型地，這樣的緩存DNS伺服器，還被稱作DNS緩存，還執行必要的遞歸算法以將以DNS根開始的給定名稱解析到所查詢域的權威名稱伺服器。網際網路服務提供商(ISP)典型地為他們的客戶提供遞歸和緩存DNS伺服器。此外，家庭網絡路由器可執行DNS緩存和代理以改進在區域網中的效率。 雖然DNS的分布特性提供在整個系統的效率方面的顯著優點，但是它還使系統對系統中各個節點處特定類型的故障和/或攻擊易損壞。可能發生的一個特別的問題被稱作DNS緩存中毒。DNS緩存中毒發生在當數據被引入到不是發源於權威DNS源的DNS名稱伺服器的緩存資料庫的時候。這可由對名稱伺服器的故意攻擊所導致，或者它可以是ー個非故意的結果，例如由於錯誤配置的DNS緩存或不適當的DNS應用軟體設計。因此，DNS緩存中毒可導致(I)解析請求失敗，例如當提供了不準確或錯誤配置的IP位址信息時，或(2)請求用戶的解析請求被指向惡意站點，其模仿真正的域並且被用於違法獲得諸如帳戶密碼等信息，或分發例如計算機蠕蟲或病毒等傳送至請求用戶的惡意內容。域名系統安全擴展(DNSSEC)是ー套用於保護如IP網絡上使用的DNS所提供的特定類型信息的網際網路工程任務組(IETF)規範。DNSSEC規定了為DNS準備的區域文件的籤名，確保DNS數據的來源鑑別和數據完整性，以及經鑑別的否定存在。一般地，DNSSEC中提供的答覆是經過數字籤名的，以及通過檢查該數字籤名，DNS解析器能夠檢查該信息是否對應於權威DNS伺服器上的信息。DNSSEC使用公鑰密碼用於數字籤名和鑑別。DNSKEY記錄通過信任鏈而被鑑別，其中信任鏈以經核實的用於DNS根區域的公鑰集(其是信任的第三方)開始。為了執行DNSSEC，多個新DNS記錄類型被創建或使適於與DNSSEC —起使用，包括RRSIG、DNSKEY, DS、NSEC, NSEC3 和 NSEC3PARAM。例如，當使用 DNSSEC 時，對於 DNS 查詢的每個權威答覆除請求的記錄類型外還將包括RRSIG DNS記錄。RRSIG記錄是答覆DNS資源記錄集的數字籤名。該數字籤名可通過定位DNSKEY記錄中發現的正確公鑰來核實。在使用信任鏈的查找過程中，在DNSKEY鑑別中使用DS記錄。NSEC和NSEC3記錄用於提供對不存在的DNS記錄的經鑑別的否定存在響應。DNSSEC的要求涉及存儲在DNSKEY記錄和來自其他源的不同密鑰的使用，以形成信任錨(trust anchor)。存在例如可用於其它DNSKEY記錄籤名的密鑰籤名密鑰(KSK)，以及可用於其他記錄籤名的區域籤名密鑰(ZSK)。由於ZSK在特定DNS區域的使用和控制之下，它們可以更容易和更經常地被轉換。結果是，ZSK—般地可以比KSK更短(在字節長度方面)，同時仍提供可接受的保護級別。
雖然已經開發了用於DNSSEC使用(包括KSK和ZSK的使用)的協議，但在註冊商和註冊局級別，存在操作DNSSEC使能(enable)域的許多方面，還沒有為大規模使用而得到解決和/或優化。例如在短時間段內處理大量籤名的能力，限制於基於區域的改變而籤名整個區域和使用獨立籤名系統的慣例。而且，可能的解決方案限定為獨立用戶，或者有限數量的域等(其可以由特定的DNS提供商管理)。從而，不斷需要進ー步改進DNSSEC記錄所需的籤名功能和有關DNSSEC管理的操作的功能性和/或效率。

發明內容
大部分當前的DNSSEC技術包括在受限的區域管理和區域服務應用內(例如由用戶、DNS提供商等限制)對DNSSEC數據進行籤名。目前，希望採用DNSSEC的用戶具有下列基本選項I.使用第三方和開源軟體連同軟體密鑰或硬體密鑰集的組合建立它們自己的DNSSEC解決方案。 2.使用 DNSSEC 密鑰管理和像 Secure64 DNS Signer、BlueCat Networks >Xelerance DNSX Secure、Signer以及Infoblox那樣的籤名工具。這樣的工具可提供不同方面的密鑰管理和區域籤名，但需要安裝在客戶端位置的硬體。應當注意DNSSEC密鑰管理和籤名工具需要客戶端位置的硬體安裝，需要密鑰資料的更實踐管理，但不支持多於單個用戶。3.使用已經被更新為支持DNSSEC的可控DNS解決方案。可控DNS提供商包括區域管理和區域發布特徵。DNSSEC啟動允許客戶端「打開」用於可控DNS區域的DNSSEC，但需要用戶向可控DNS提供商轉移或外包他們的DNS主機。然而，隨著DNSSEC被弓I入大量註冊局，例如.com和.net註冊局，用於DNSSEC數據的各種籤名技術的無效率，特別對於大區域，帶來潛在解析問題，包括延遲和解析失敗。這樣的問題可在電子商務和其他高業務量位置具有顯著有害的影響。本主題可以通過使用網絡可訪問籤名伺服器對DNSSEC使能(enable)區域的有效籤名方面提供優勢，所述網絡可訪問籤名伺服器允許遠程應用管理籤名並且還根據需要對區域數據的部分進行遠程籤名。根據本發明的方面，與其他那些功能基本上合併進去的技術相比(例如在名稱伺服器執行籤名的技術中，或者特定的區域管理設備執行籤名的情況)，使用網絡可訪問籤名伺服器可以提供區域管理和區域服務應用從籤名機制中的去耦。通過使用，例如，可擴展的、網絡可訪問的籤名伺服器，示例的配置與其他已知的技術相比，還可以減少或者消除手動配置籤名伺服器的各種功能的需求。網絡可訪問籤名伺服器還可以提供對寬範圍的DNSSEC應用的支持，無需手動配置，諸如I.將資源記錄的籤名內嵌在高容量的DNSSEC應用中，例如TLD註冊局。2.在具有很多密鑰和區域的DNSSEC應用中動態生成密鑰、加載密鑰、下載密鑰並使用密鑰籤名區域數據。3.在離線/批量DNSSEC應用中簽名整個區域，例如ROOT區域。在實施例中，用於執行DNSSEC籤名的系統和方法可以由籤名伺服器執行，所述籤名伺服器配置為與單獨的客戶端應用進行交互。示例的方法通常包括在籤名伺服器接收來自客戶端應用的籤名請求以籤名第一數據。籤名伺服器可以為該第一數據確定合適的籤名密鑰和/或協議。該第一數據接著由籤名伺服器發送到數字籤名模塊，其可以包括，例如，硬體支持模塊或者軟體籤名應用。籤名伺服器可以從數字籤名模塊接收第一數據的數字籤名版本，並將經籤名的第一數據提供給客戶端應用。根據發明的第一方面，DNSSEC籤名伺服器可以配置為與至少ー個DNSSEC客戶端應用和數字籤名模塊交互。DNSSEC籤名伺服器可以包括，例如，處理器和包括計算機可讀代碼的存儲設備，所述計算機可讀代碼當由處理器執行時，使得籤名伺服器充當配置為從至少ー個客戶端應用接收籤名請求以籤名第一數據的權威籤名伺服器。第一數據可以包括，例如，DNS數據。在實施例中，籤名伺服器可以為第一數據確定合適的籤名密鑰，例如，激活KSK和激活ZSK中的至少ー個。合適的密鑰，諸如激活KSK和激活ZSK中的至少ー個可以基於例如包含在籤名請求中的TLD標識符確定。在實施例中，籤名伺服器可以配置成為第一數據確定多於ー個的激活籤名密鑰和/或激活籤名算法，並可以基於多於ー個的激活籤名密鑰和/或激活籤名算法為第一數據請求多個不同的籤名。 在實施例中，籤名伺服器可以發送第一數據到多個數字籤名模塊中的ー個，並可以從數字籤名模塊接收第一數據經數字籤名的版本。籤名伺服器還可以配置為向客戶端應用提供經籤名的第一數據。在實施例中，籤名伺服器可以配置為基於包含在籤名請求中的服務類型標識符在多個不同的數字籤名功能中區別所請求的籤名功能，並基於該服務類型標識符將非DNSSEC籤名請求路由到非DNSSEC數字籤名模塊。根據發明的另ー個方面，籤名伺服器還可以配置為接收(作為相同籤名請求的一部分)請求以籤名第二數據。該第二數據可以是，例如，DNS或者其他數據。籤名伺服器可以為第二數據確定合適的籤名密鑰，例如激活KSK和激活ZSK中的至少ー個，該籤名密鑰不同於用於第一數據的密鑰。例如，籤名伺服器可以為第一數據確定第一密鑰集，為第二數據確定第二密鑰集。在實施例中，籤名伺服器可以將第二數據發送到多個數字籤名模塊中的ー個，並從該數字籤名模塊接收第二數據經數字籤名的版本。籤名伺服器還可以配置為向客戶端應用提供籤名的第二數據。實施例可以包括其中簽名伺服器配置為接收多個籤名請求作為單個請求分組的一部分，並對請求分組進行分析以識別具有彼此不同的激活KSK、激活ZSK和籤名協議中的至少ー個的不同的籤名請求。 在實施例中，數字籤名模塊可以配置為根據DNSSEC協議對DNS數據的特定部分進行籤名，而不是籤名整個區域。在實施例中，籤名伺服器還可以配置為提供額外的非DNSSEC數字籤名功能。在實施例中，每個數字籤名模塊可以包括硬體支持模塊(HSM)，其在物理上與籤名伺服器的處理器分離並配置為對由籤名伺服器提供的數據進行數字籤名。在實施例中，HSM可以包括多個根據別名標識符識別的密鑰。籤名伺服器可以配置為將用於要使用的合適密鑰(諸如用於DNS數據的KSK和ZSK中至少ー個)的別名標識符傳遞給數字籤名模塊，而不傳遞至少ー個KSK和ZSK給數字籤名模塊。在實施例中，籤名伺服器可以配置為定期檢查激活密鑰(例如激活的KSK或ZSK)的資料庫，並基於從資料庫接收的信息確定對於給定時間哪個別名標識符是激活的。在實施例中，傳遞到數字籤名模塊的別名標識符可以是激活的別名標識符。在實施例中，籤名伺服器可以配置為基於至少ー個激活KSK和/或激活ZSK識別特定HSM來發送第一數據。在實施例中，籤名伺服器可以配置為處理關於不同TLD下的域的請求。在實施例中，籤名伺服器可以配置為處理關於由多個註冊商管理的至少兩個域的請求。在實施例中，客戶端和籤名伺服器之間的通信可以，例如，通過雙向SSL實現。如此處所討論的，示例的籤名伺服器可以支持由眾多的不同系統實施的各種DNS操作籤名操作，包括，例如，DNSSEC籤名功能、其他受控DNS服務、遠程籤名、根區域籤名等 等。在實施例中，示例的籤名伺服器可以配置為支持例如作為單個事務(即工作的極小的、一致的、孤立的和持久的單元)的部分的受影響的DNSSEC記錄的籤名，所述單個事務各個方面在此處可以稱為「內嵌籤名」。本發明的附加特徵，優點和實施例根據以下詳細的說明，附圖和權利要求的考慮已經闡述或顯而易見。此外，將要理解本發明的前述概要和以下詳細的說明是示例性的並且打算提供進ー步解釋而沒有限制所要求保護的本發明的範圍。然而詳細說明和具體示例僅指示本發明的優先實施例。在本發明的精神和範圍內的各種變更和改變從該詳細的說明將對本領域技術人員來說是顯而易見的。


被包括用以提供本發明進一歩理解的附圖，被合併進來並且構成本說明書的一部分，其示出了本發明實施例，並且與詳細描述一起用於解釋本發明的原理。不嘗試比可能對本發明的基本理解必要的細節更詳細地示出本發明的結構細節以及其可能被實施的不同方式。在圖中圖I描述了根據本發明的方面的一個示例的DNSSEC使能的籤名系統的細節。圖2描述了根據本發明的方面的DNSSEC使能的籤名系統的進一歩的細節。圖3描述了根據本發明的方面的一個示例的籤名請求協議。圖4描述了根據本發明的方面的一個示例的籤名請求數據協議。圖5描述了根據本發明的方面的另ー個示例的籤名請求數據協議。圖6描述了根據本發明的方面的ー個示例的籤名響應協議。圖7描述了根據本發明的方面的一個示例的籤名響應數據協議。圖8描述了根據本發明的方面的另ー個示例的籤名響應數據協議。圖9描述了根據本發明的方面的示例的請求、請求數據、響應和響應數據的關係。圖10描述了根據本發明的方面，ー個包括籤名服務客戶端池管理器的示例的DNSSEC使能的籤名系統的進ー步的細節。圖11描述了根據本發明的方面可以被支持的用於DNSSEC籤名的一個示例的內嵌籤名技術的示意性系統布置。圖12描述了可以在本發明的實施例中使用的一個示例的計算機網絡結構。
具體實施例方式可以理解的是本發明並不限於在此描述的特殊方法、協議等，這些可改變，正如本領域技術人員將認識到的那樣。還需要理解的是在此使用的術語僅用於描述特殊實施例的目的，但不打算限制本發明的範圍。還需要注意如在此和在附加權利要求中使用，単數形式「一」、「ー個」和「該」也包括複數引用，除非上下文明確做出其他指示。因此，例如提到「月艮務器」是指ー個或多個伺服器以及本領域技術人員所知的等價物。除非定義為其他，在此使用的所有技術術語具有與本發明所屬技術領域普通技術人員所普遍理解的相同含義。參考在附圖中描述和/或闡明以及在以下描述中詳述的非限制實施例和示例而更充分地解釋本發明的實施例及其各個特徵和優點。應當注意的是圖中闡明的特徵不必依比例畫出，並且如本領域技術人員會意識到的一個實施例的特徵可由其他實施例所使用，即使在此沒有明確地陳述。公知的部件和處理技術的描述可以被省略使得不會不必要地模糊本發明的實施例。在此使用的示例僅打算促進理解可實施本發明的方式，並且進一歩使本領域技術人員能夠實施本發明的實施例。從而，在此的示例和實施例不應當解釋為限制本發明的範圍，其僅由所附權利要求和適用的法律定義。此外，注意在附圖 的各視圖中類似的附圖標記涉及相似的部分。如在此使用的，除非其他限制，註冊商可被理解為與域名註冊局互動並允許註冊者建立和更新域名資源的任何實體或組織。如在此使用的，除非其他限制，註冊者可理解為與註冊商互動以建立和更新域名資源的任何個人或組織。如在此使用的，除非其他限制，DNS主機提供商可理解為代表註冊者在其伺服器上寄存(host)內容的任何實體或組織,為該內容提供DNS供應(provisioning)和解析能力(例如，分配IP位址並操作能夠將域名解析到其管理的那些IP位址的名稱伺服器)。本發明的實施例可以提供網絡可訪問的DNSSEC籤名技術以允許大型DNSSEC提供商，諸如註冊局，以有效和一致的方式處理來自各個源的大量DNS改變(包括DNSSEC籤名數據)。區域籤名概述如上所述，DNSSEC被設計用來解決緩存中毒及一組其他DNS脆弱性，例如中間人攻擊和在權威伺服器上的未授權數據變更。其主要目的是提供來源鑑別和DNS數據完整性保護。公鑰基礎結構(PKI)可被用作公鑰分發的方式。DNSSEC提供了 DNS數據的核實機制但不是加密機制。它允許可感知安全性的解析器來核實接收到的區域數據由持有私鑰的區域管理者籤名。DNSKEY資源記錄區域可以具有ー個或多個密鑰對，每ー對包含私鑰和公鑰。私鑰可安全地保存在域名資料庫中並用於區域數據籤名。公鑰可以存儲在資料庫中也可以作為DNSKEY資源記錄存儲在已籤名的區域數據中。公鑰用於核實區域數據。DNSKEY記錄典型地含有下述數據元素標誌「區域密鑰」和「安全入ロ點」協議固定值為3 (用於向後兼容)算法公鑰的密碼算法
公鑰公鑰數據DNSKEY資源記錄(「RR」)可以為區域籤名密鑰(ZSK)或密鑰籤名密鑰(KSK)。密鑰籤名密鑰(KSK)將具有SEP標誌集，以使它們能與DNSKEY RR集中的ZSK區分開。密鑰籤名密鑰(KSK)用於對其他DNSKEY資源記錄籤名，也用於對需要驗證的數據建立權限(,authority)鏈。RRSIG資源記錄RRSIG資源記錄擁有資源記錄集RR集(具有相同名稱、類別和類型的ー個或多個DNS記錄)的DNSSEC籤名。DNSSEC使解析器能夠利用存儲在DNSKEY記錄中的公鑰來核實籤名。RRSIG記錄含有下述數據元素覆蓋類型該籤名所覆蓋的DNS記錄類型。

算法用於創建籤名的密碼算法。標籤 原始RRSIG記錄名稱中的多個標籤(用於驗證通配符)。初始TTL :覆蓋的記錄集的TTL值。籤名到期籤名何時到期。籤名起始籤名何時創建。密鑰標記有助於快速識別可用於驗證該籤名的DNSKEY記錄的短數值。籤名器名稱可用於驗證該籤名的DNSKEY記錄的名稱。籤名密碼籤名。DNSKEYRR由激活的KSK和ZSK籤名。其他RR集僅由激活的ZSK籤名。NSEC資源記錄NSEC資源記錄列出了兩個獨立的事物包含權威數據或委託點(delegationpoint) NS RR集的下一個持有者名稱(以區域的規範順序)，和出現在NSEC RR持有者名稱中的RR類型集(RFC3845)。區域內的NSEC RR的完整集指出哪些權威RR集存在於區域中並還形成區域中權威持有者名稱的鏈。這些記錄作為DNSSEC驗證的一部分可由解析器用於核實記錄名稱和類型的不存在性。NSEC記錄具有下述數據元素下一個域名區域中下一個記錄的名稱(DNSSEC排序順序)。記錄類型為NSEC記錄的名稱而存在的DNS記錄類型。NSEC3資源記錄NESC3資源記錄(RR)為DNS資源記錄集提供經鑑別的否定存在。NSEC3RR具有與NSEC RR相同的功能，除了 NSEC3使用加密的散列記錄名稱以防止區域中記錄名稱的枚舉之外。NSEC3記錄連結到區域中的下一個記錄名稱(以散列名稱排序的順序)並列出為了NSEC3記錄持有名稱的第一標籤內由散列值所覆蓋的名稱而存在的記錄類型。這些記錄可作為DNSSEC驗證的一部分而由解析器用於核實記錄名稱和類型的不存在性。NSEC3記錄含有下述數據元素散列算法所用的密碼散列算法。標誌「Opt-out」 (指出委託是否被籤名)。迭代散列算法被應用了多少次。加鹽(salt):用於散列計算的加鹽值。
下一散列持有者名稱區域中下一個記錄的名稱(以散列名稱排序的順序)。記錄類型為了 NSEC3記錄持有名稱的第一標籤內由散列值覆蓋的名稱而存在的記錄類型。圖I中示出了一個示例性籤名伺服器布置的方面。如圖I所示，註冊局或其他DNSSEC服務提供商可以包括任何數量的籤名伺服器142、146。例如，多個籤名伺服器可以包括註冊局供應系統。籤名伺服器142、146可以分別包括硬體支持模塊(HSM)144、148和/或軟體，其可以具有包括合適的數字籤名密鑰的實際數字籤名功能。籤名伺服器142、146可以與各種應用、服務和工具110、120和130通信，以及例如交換已籤名和未籤名的DNS數據。每個CAS110、NCC插件商業服務120和批量/工具130組件將具有與籤名伺服器(優選地這樣的伺服器集)的連通性(connectivity)。籤名伺服器142、146可以將已籤名的DNS數據保存到資料庫150。在應用、籤名伺服器、HSM和資料庫之間的示例數據流的附加細節在圖2中示出。

如圖2所示，客戶端210可以代表，例如供應系統的前端服務，其可以被配置為識別需要由籤名伺服器212籤名的DNSSEC數據。將被籤名的數據可以是，例如，受DNS改變(例如域的増加、更新、刪除命令)影響的區域數據的一部分。DNSSEC或者其他將被籤名的數據可以基於例如域命令而被分析(parse)或以其他方式識別，並提供給籤名伺服器212，如鏈路241所示。客戶端210和籤名伺服器212之間的通信可以例如通過雙向SSL隧道。諸如字節、密鑰類型(ZSK，KSK)和TLD等的信息可以包含在請求中。籤名伺服器212可以識別來自傳輸241的合適的密鑰信息和/或HSM，並將未籤名的數據傳遞給合適的HSM214，由鏈路242示出。這可以包括具有，例如字節、密鑰別名和籤名算法的籤名命令。在實施例中，籤名伺服器212還可以接收對其他數據進行籤名的請求，作為相同籤名請求的一部分。籤名伺服器212可以為其他數據確定合適的密鑰信息。在實施例中，如此處進一步描述的，其他數據的密鑰信息可以與包含在相同籤名請求中的第一數據的密鑰信息不同。從客戶端210向籤名伺服器212的請求241可以根據籤名伺服器協議(SSP)進行格式設置。在實施例中，示例的協議可以包括「車箱」(boxcar)格式，其中多個籤名請求可以被打包成單個的協議請求，從而優化降低性能的網絡往返和帶寬利用。另外，SSP可以包括每個服務模塊遵循的內建診斷特徵，允許客戶端確定服務的可用狀態和近來的問題。在實施例中，此處描述的協議可以允許，特別是加入到籤名伺服器的新服務模塊所需要的新數據傳送分組構成的即時可插性(pluggability),而不改變傳送協議本身。圖3示出了一個示例的SSP，在下文中進ー步進行描述。如圖3所示，來自客戶端的籤名伺服器請求協議300可以包括如下欄位分組長度=int (分組的總長度)協議版本=字節(協議的版本)服務類型=字節(例如，簡單(對於通用籤名)；DNSSEC (對於DNSSEC籤名)；公鑰取回(給定密鑰別名，返回公鑰))。事務Id ::=長(識別請求的P隹ー id)標誌=int (標誌中允許請求傳遞的欄位，(服務-不可知(agnostic)))。會話Id::=長(發送請求的會話Id，可用於審核的目的)。
帳戶Id::=長(發送請求的帳戶Id，可用於審核的目的)。記錄數目=字節(請求數據的數目(即，包含在整個請求(服務需要對其採取行動)中的分組的數目))籤名請求數據L . . n-數據的(ー個或多個)分組(服務需要對其採取行動)；通常其包括將要籤名的數據。客戶端210可以發送籤名請求數據作為其請求300內的有效載荷。在實施例中，籤名伺服器212可以配置為對不同的服務請求進行識別和採取行動，並基於，例如相關的編解碼器對數據有效載荷進行解碼。在實施例中，數據可以以各種形式構造，其可以稱為「籤名請求數據協議」，包括，例如，下文進ー步討論的SimpleSigningRequestData、RRSigSigningRequestData 或 PublicKeyRetrievalRequestData。圖4示出了簡單籤名請求籤名請求數據協議(Simple Signing Request Signing Request Data Protocol)的舉例。如圖 4 所不，簡單籤名請求(Simple SigningRequest) 310可以包括長度=int (數據的長度)算法=串(籤名算法)密鑰別名=串(需要用於籤名的密鑰別名)請求數據長度=int (請求數據欄位的長度)請求數據=字節(需要被籤名伺服器籤名的數據)如上面提到的，客戶端210、籤名伺服器212和HSM214可以使用密鑰別名來識別特定的密鑰。從而，各個組件不需要交換真實密鑰，這在基本上不可訪問狀態下(例如，不能通過網絡訪問)維持密鑰材料安全性方面具有優勢，尤其是特定組件(例如HSM214中)維持的密鑰。如圖5 所不，RRSigSigningRequestData,可以用於以與 SimpleSigningRequest 類似的方式實現籤名請求數據。該RRSigSigningRequestData可以是例如由客戶端填充的數據豆(data bean),保存關於需要被籤名的RRSIG記錄的信息。如下文進ー步討論的,姆一類別的請求可以由籤名伺服器212返回，作為相應的響應244。應當指出，當籤名伺服器212接收請求241時，可以用其自身的DNSSEC相關數據或其他數據擴充(augment)該請求數據。RRSigSigningRequestData320 可以包括長度=int (數據長度)RRSIG ID::=長度(RRSigSigningRequestData 的P隹一 ID)域名=串(域的名稱)域Id ::=長度(域的id)父域=串(父域)覆蓋類型=int (資源記錄類型)標籤數目=int (域名中標籤的數目)初始TTL::=長(需要由籤名伺服器籤名的數據)TTL :=長(需要由籤名伺服器籤名的數據)RR開始時間=長(RRSIG開始時間的紀元時間(epoch time))
RR集字節長度=int (RR集字節的長度)RR集字節=字節(需要由籤名伺服器籤名的數據)相應地，考慮到圖3中所示的籤名伺服器請求協議300、圖4中所示的SimpleSigningRequestData 310 和圖 5 中所不的 RRSigSigningRequestData 320 的組合，適當配置的籤名伺服器可以接受具有多個籤名請求數據的單個籤名請求(例如，通過籤名伺服器請求協議300)，每個籤名請求數據具有潛在的不同籤名算法、密鑰別名等。如此處進一步討論的，在RRSigning數據的情況下，合適的算法和/或密鑰可以基於例如識別的域和/或與請求相關的TLD。在實施例中，籤名伺服器可以配置為通過對此處描述的請求和數據分組進行分析來處理關於不同TLD下域的請求，和/或處理關於由多個註冊商管理的至少兩個域的請求。籤名請求數據協議還可以包括PublicKeyRequestData(未示出)，包括下列欄位 長度=int (數據的長度)密鑰別名=串(用於取回公鑰的密鑰別名)籤名伺服器212可以配置為定期核對用於權威數據的資料庫220，以檢查在向HSM214發送數據時使用的密鑰別名。籤名伺服器212還可以配置為基於激活的KSK和/或激活的ZSK識別發送數據分組的特定HSM。HSM214可以在初始化時在每個TLD加載多個密鑰(有些可以是ZSK，有些可以是KSK)，HSM214可以通過別名、密鑰別名知道每個密鑰。客戶端210可以配置為告知籤名伺服器212使用了兩種密鑰中的哪ー種(ZSK還是KSK)以及TLD，而籤名伺服器212可以配置為當與HSM因為籤名而進行通信時識別那種密鑰的當前密鑰別名名稱。籤名伺服器212還可以被強制重新核對資料庫220以檢查當前的密鑰別名。這個命令可以通過JMX管理接ロ發給例如籤名伺服器212。相應地，籤名伺服器212可以理解為 「DNSSEC 感知」(DNSSEC-aware)。使籤名伺服器DNSSEC感知的一個好處是節省了客戶將不得不以其他方式傳遞的數據與幾乎每個籤名請求進行編組和解組(即使那些數據沒有改變)。也就是，客戶端210不需要知道沒有頻繁改變的數據，客戶端210也不用與每個請求241 —起發送沒有頻繁改變的數據。更確切地，籤名伺服器212本身可以知道並緩存那些數據。籤名伺服器212還可以配置為也提供通用籤名能力。實例包括配置籤名伺服器用幹與可控DNS服務一起使用，該籤名伺服器具有大量的密鑰和區域(成千上萬)以生成用於可控DNS服務、根區域籤名等的各種籤名。在實施例中，客戶端可以配置為和動態加載能カー起提供籤名參數並上傳用於籤名的密鑰。能夠執行多種類型的籤名事務的「通用籤名」籤名伺服器可以提供靈活的應用以用幹與例如大規模多功能的可控DNS服務一起使用。從而，籤名伺服器212DNSSEC感知，並能夠例如通過運行時間可配置的插件(服務)為了其他籤名目的而工作，伺服器依賴該插件處理進入請求。根據本發明的方面，籤名伺服器框架，如圖2所示，可以允許各方編寫包括不同的參數和密鑰的服務模塊，其可以與各種品牌的硬體或軟體籤名器應用進行通信。可以在協議中加入額外的功能以支持新的特徵而不妨礙現有的客戶端。籤名伺服器和籤名伺服器協議的配置可以允許，例如，DNSSEC應用包括其他不同定義的終端用戶接ロ(例如，網頁服務、EPP、REST)而不影響基本籤名。實施例可以包括具有服務模塊的籤名伺服器代碼庫，該服務模塊提供籤名配置參數的緩存和不緩存組合。服務模塊從而可以根據其需要重新使用這些緩存和不緩存特徵。緩存可以用於提高具有相對穩定的密鑰和籤名配置的服務模塊的性能，而不緩存可以方便密鑰和籤名參數的按需加載，用於需要大量僅在籤名時激活的離線存儲的密鑰和參數的情況。此外，當個別服務模塊故障或變得不可用(不同協議和密鑰時可能會發生)，籤名伺服器本身可以保持穩健並允許其他模塊繼續服務請求。這種靈活性可以提供例如目前獨立DNSSEC籤名應用無法完成的大量選項。不緩存方式(例如所有適用的密鑰都不在HSM或其他籤名模塊中緩存)的ー個特定優點是數位化包裝的密鑰可以存儲在更便宜和更高可用性的存儲庫中，例如易於跨數據中心複製的資料庫等。然後HSM或其他籤名模塊可以按需取回密鑰來籤名數據。這種真實密鑰的単獨存儲、按需加載已經被發明人發現，使得整個籤名服務(例如此處描述的)能夠縮放(scale)更大量的密鑰而不會犧牲HSM的性能能力或者使用的資料庫的可用性。這已經被發現在極大規模的DNS服務的上下文中尤其有用，例如該極大規模的DNS服務可以由註冊局提供，其可能需要為成千上萬的區域訪問密鑰。在實施例中，HSM或其他籤名模塊，可以用HSM或其他籤名模塊的私鑰對存儲在數 據庫中的有關密鑰進行加密。如此處進一步描述的，每ー個密鑰是可以由密鑰別名識別的，並在取回時可以由HSM或其他籤名模塊使用私鑰進行解密。返回圖2，HSM214可以對，例如在請求242中接收的DNSSEC數據以合適的密鑰進行籤名，並將籤名的數據回傳給籤名伺服器212，如鏈路243所示。在實施例中，這種籤名可以基於，例如，根據包含在請求中的密鑰別名等識別適當的密鑰和/或協議。或者，HSM或者其他軟體籤名應用可以具有預先確定的密鑰和/或參數以應用於指向它們的籤名請求。應當指出，根據本發明的包括分開識別包含在籤名請求中的數據分組的方面，分組可以異步處理，從而客戶端能夠持續處理而不會由於籤名響應而發生阻塞。進ー步地，單個籤名伺服器可以接收並作用於請求以同時跨應用和跨區域籤名數據。即，單個伺服器可以在單個請求分組中接收命令以籤名彼此不相關、跨區域和/或應用的數據。另外，籤名伺服器212可以配置成為單個數據分組請求並提供多個籤名。例如，籤名伺服器212可以識別不止ー個要應用到特定數據的激活的密鑰和/或算法，並可以基於該不止一個激活的密鑰和/或算法從HSM或其他籤名模塊請求多個籤名。在實施例中，籤名伺服器212可以配置為請求並報告，例如通過第一算法使用第一密鑰對第一數據的籤名和通過第二算法使用第二密鑰對第一數據的籤名。例如，根據用戶要求，在密鑰翻轉(rollover)的上下文和/或為了 DNSSEC有效實現算法運作(roll)(例如，SHA-1到SHA-2)，可以應用多個激活的密鑰和籤名。HSM 214可以在物理上與籤名伺服器212的處理器分開，並且可以包括，例如，額外的安全協議以保護存儲在HSM 214中的密鑰。例如，HSM 214可以配置為僅通過物理加載過程交換特定密鑰信息以保護存儲在其中的密鑰，尤其是那些使用壽命長或具有廣泛應用性的密鑰，如KSK。在實施例中，HSM可以包括一個或多個密鑰和一個或多個識別存儲在其中的密鑰的別名標識符。籤名伺服器212可以將籤名的數據，例如DNSSEC或其他數字籤名的數據，或者其他數據，諸如事務提交信息，返回給客戶端210，如鏈路244所示。如上指出，每ー類別的請求可以由籤名伺服器212返回，做為相應的響應244。由籤名伺服器212返回的響應244可以配置為遵循如圖6所示的籤名伺服器響應協議。
如圖6中所示，籤名伺服器響應協議400可以包括，例如分組長度=int (分組的總長度)協議版本=字節(與在請求中發送的相同)服務類型=字節(與在請求中發送的相同)事務Id::=長(與在請求中發送的相同)標誌=int (標誌中允許傳遞請求的欄位(服務-不可知(agnostic)))響應代碼=字節(處理請求後的響應代碼。見下文用於可由籤名伺服器返回的響應代碼。)

響應消息長度=int(用於由伺服器返回的響應的詳細響應消息的長度。)響應消息字符=char (響應消息字符)。記錄數目=字節(響應數據的數目(例如包含在服務需要在其上起作用的總請求中的分組的數量)。)籤名響應數據I... n。表I中示出了示例的籤名響應代碼表I
響應代碼響應描述
0
~請求失敗
2由於資料庫故障，請求失敗
由於籤名引擎故障，請求失敗~由於不支持的服務請求，請求失敗
~沒有找到密鑰別名的公鑰籤名響應數據可以包括，例如對應於請求SimpleSigningRequestData、RRSigSigningRequestData 或者 PublicKeyRetrievalRequestData的 SimpleSigningResponseData、 RRSigSigningResponseData 或者PublicKeyRetrievalResponseDatao在實施例中，對於在請求中發送的姆個請求_數據分組可以有一個響應數據對象。圖7中示出了一個示例的SimpleSigningResponseData410,例如，其由籤名伺服器212返回，作為對諸如圖4中所示的SimpleSigningRequest的響應。如圖7所示，SimpleSigningResponseData410 的欄位可以包括長度=int (數據的長度)籤名的數據長度=int (籤名的數據欄位長度)籤名的數據=字節(需要由籤名伺服器籤名的數據)圖8示出了 RRSigSigningResponseData420的一個實例，其可用於由諸如圖5所示的RRSIG相關的請求產生的姆個響應-數據分組。RRSigSigningResponseData420的欄位可以包括長度=int (數據的長度)RRSIG ID::=長(RRSigSigningRequestData 的P隹一 ID)域名=串(域的名稱)域Id ::=長(域的 id)父域=串(父域)覆蓋類型=int (資源記錄類型)
標籤數目=int (域名中標籤的數目)初始TTL::=長(需要由籤名伺服器籤名的數據)TTL :=長(需要由籤名伺服器籤名的數據)RR開始時間=長(RRSIG開始時間的紀元時間)密鑰標記=int (用於對該請求進行籤名的密鑰的密鑰標記)算法Id : = int(用於對該請求籤名的算法Id)籤名=串(由籤名該請求產生的基本64編碼籤名)RR結束時間=長(RRSIG結束時間的紀元時間)籤名響應數據還可以包括PublicKeyResponseData(未示出)，其包含如下欄位長度=int (數據的長度)密鑰別名=串(在請求中發送的密鑰別名)公鑰=串(使用密鑰別名取回的密鑰的基本64編碼公鑰)一旦籤名的數據返回到客戶端210，客戶端可以根據需要分發籤名的數據，例如到DNS或者其他服務，和/或根據需要發送確認消息。在實施例中，客戶端210可以配置為DNSSEC應用，其可以識別並作用於DNS改變等，以及確定需要執行的合適的DNSSEC功能。從而，籤名伺服器212可以減少許多DNSSEC專用的應用編程和功能。DNSSEC應用，例如客戶端210，可以專注於DNSSEC商業邏輯(什麼資源記錄需要被籤名等)而不必關心籤名參數的細節，也不會產生集合併傳遞額外的信息到籤名伺服器212所導致的處理和網絡成本。同樣，如上所述，各種請求和響應協議使DNSSEC應用能夠將所有相對較小的籤名請求(完全沒有各種DNSSEC籤名參數和密鑰信息)組合為單個分組，從而極大減小了網絡複雜和開銷。最終，客戶端210還可以減少任何HSM接ロ細節。圖9以圖示地描述了在客戶端和伺服器間共享的上述討論的示例性的請求和響應協議的關係。應當指出，上述的協議和具體內容在本質上僅是舉例，不將本發明的範圍限制到這種具體的協議。例如，可以實現利用智能籤名伺服器能力的其他協議，例如，密鑰清單加載到籤名伺服器中，客戶端僅需要傳遞要籤名的數據和用於籤名伺服器自動選擇正確的密鑰的合適標識符。根據本發明的另ー個方面，如此處所述，可以管理客戶端和籤名伺服器的集群以提高籤名系統的負載平衡和響應能力。例如，如圖10所示，在實施例中，對於每個籤名伺服器801-801n，可以有ー個SigningServerClient 810的實例來處理對於特定籤名伺服器的請求。在 SigningServerClient 810 之上還可以有 SigningServiceClientPool 820,其管理 SigningServerClient 實例。SigningServiceClientPool 820 可以連接到任意數量的SigningServerClient,並且可以配置為,例如，以例如循環(round robin)的方式向各種籤名伺服器加載平衡請求，如果其連接到的籤名伺服器不工作將SigningServerClient實例移出輪換等。每個SigningServerClient 810可以配置為維護與籤名伺服器的套接(socket connection)池 812,如果該服務掉線通知 SigningServiceClientPool 820 並啟動健康檢查線程，和/或在籤名伺服器恢復運作後不斷嘗試連接籤名伺服器並通知SigningServiceClientPool 820 將該服務放回輪換中。相應地，整個系統可以適應客戶端側和伺服器側的故障。例如，客戶端側服務維護籤名伺服器的列表並對已識別的來自那些伺服器的「致命」異常/錯誤響應做出反應。客戶端側可以將那些出現故障的籤名伺服器從循環輪換中移出，並可以在伺服器恢復在線時不斷嘗試識別。籤名伺服器可以配置為支持「ping」使得客戶端可以檢查其健康。如果客戶端側的籤名服務發現其所有的籤名伺服器都不工作，它可以在接收到對 某些東西籤名的請求時立即返回異常。客戶端可以持續這樣做直到至少ー個籤名伺服器變得可用。來自籤名伺服器側的故障情況可以包括ー個其附屬物(如HSM或密鑰資料庫)不可用。如果HSM不可用，籤名伺服器可以報告指示這個的錯誤響應。籤名伺服器可以在這種情況下通過，例如，JMX和日誌條目進行警示。籤名伺服器也可以不斷嘗試檢查HSM是否恢復在線。如果密鑰資料庫對於密鑰數據的刷新變得不可用，籤名伺服器可以配置為拒絕籤名數據的請求(例如，因為它承擔使用錯誤密鑰籤名的風險)。籤名伺服器可以配置為報告這個錯誤作為籤名響應，並可以不斷嘗試連接回密鑰資料庫。另ー個選項是將籤名伺服器配置為在服務不能正常工作時將客戶端連接「掉線」(drop)和/或停止對特定服務的新連接的監聽。這種配置，例如，可以有利於使客戶端僅將服務請求指引到目前可操作來實現服務的籤名伺服器，提高了籤名服務網絡的狀態監測，減少了回報給客戶端的錯誤數量，並且提高了客戶端的整體效率。這種配置還可以在問題得以解決之前使籤名伺服器繼續其他可操作服務，而對於不工作的服務沒有遭遇和/或報告錯誤的負擔。類似的配置可以應用於籤名伺服器和多個輔助HSM或其他籤名模塊之間。根據圖1、2和10中描述的布置和上面詳細描述的請求和響應協議的方面，客戶端(例如客戶端210)可以採用技術和客戶端實用工具庫來提供負載平衡和高的可用特徵。例如，無論其正在使用伺服器內部的哪個服務模塊，客戶端實用工具庫都可以與籤名伺服器進行交互。客戶端實用工具庫可以提供自動重連和快速-失效(fast-fail)(服務不可用的時間)作為其特徵集的一部分。客戶端實用工具庫的負載平衡特徵還可以有助於確保在任何時候，無論多少籤名伺服器可用和不可用，無論多少客戶端連接到這些伺服器，負載都將自動地相對均勻地分布在激活伺服器之間。在實施例中，用於籤名伺服器的服務模塊外掛(plug)可以包括用於ー個或多個TLD (諸如.com, . net, . net, . edu等)的模塊。在實施例中，知到用於不同TLD的各種密鑰清單和/或協議的單個服務模塊可以支持多個TLD。服務模塊可以配置為提供，例如，給定籤名所應用的以及負責密鑰翻轉的TLD，根據需要將使用哪個ZSK產生數字籤名；哪個硬體或軟體籤名器應當為該TLD產生籤名；當產生籤名時使用哪種TLD專用參數，包括加鹽、散列算法、籤名算法、籤名持續時間等。在實施例中，籤名伺服器可以配置為自動定期地從資料庫重新加載這些設置，從而可以在正常操作過程中拾取(pick up)改變，而不必重新啟動。這種方式的ー個特別優勢是可以提供ー種集中式的權威配置，保證每個TLD的一致的籤名生成。而且，這意味著用於TLD的註冊局應用本身可以不必直接知道這些策略，而是請求籤名伺服器對數據籤名並依賴籤名伺服器在籤名時在每個TLD基礎上應用所需的策略和參數。這種方法可以降低註冊局作為整體當在正常操作過程中那些數據改變時對於籤名配置數據過期的風險，因為，例如，籤名伺服器比註冊局應用實例少得多。而且，到籤名伺服器的客戶端不需要具有額外的與加載TLD專用籤名參數相關的配置和應用邏輯(其會增加應用的複雜性並提高誤配置的風險，導致數字籤名失敗)。最後，客戶端不必與每個請求一起傳送TLD專用籤名參數給籤名伺服器，這意味著降低了網絡負載，提高了呑吐量。更一般來說，根據本發明的方面，籤名伺服器可以配置為考慮到開發者插入「智能」服務，其中服務基於籤名請求的上下文保存關於哪個密鑰被激活、將使用哪種算法等等 的知識，上下文本身不包括該信息。這尤其是在那些客戶端意欲保持儘可能「沉默」(dumb)的上下文中是優選的。這可以用於，例如，實現更小的分組，減少客戶端操作過期信息或與密鑰狀態不同步的可能，並提供了更小的容量和較不脆弱的客戶端代碼。如前面提到的，此處所述的籤名伺服器方法和裝置可以發現適用性併兼容於龐大的DNS陣列和其他籤名、服務。例如，通過提供網絡可訪問、可配置的籤名伺服器，可以容易地支持各種遠程籤名協議和配置。可以支持的一個這種非限制性示例包括「在線籤名」布置，其可用於此處描述的DNSSEC籤名功能，細節在圖11中示出。如圖11所示，請求者1000，諸如例如註冊者、註冊商或DNS提供商，可以與註冊局供應系統1100通信。請求者1000可發送有關已存在或新的域的命令。例如，請求者1000可發送命令以改變註冊局管理的DNS數據，例如在註冊局管理的TLD (如.com)下的域的DNS數據。註冊局供應系統1100可以以各種方式處理來自請求者1000的域命令，包括，例如執行改變命令，如添加，變更，或刪除命令，識別DNSSEC數據改變，識別合適的密鑰，應用數字籤名，將DNS和DNSSEC改變保存在註冊局資料庫1200等。由註冊局供應系統1100向註冊局資料庫1200提供的數據可以包含域的DNS信息和已籤名DNSSEC數據。在實施例中，示例的籤名伺服器可以支持，例如，在單個事務中實現DNS改變和DNSSEC改變的方法。如上所述，DNSSEC籤名可以由籤名伺服器實現，同步地內嵌(inline)有事務。單獨的服務可以用於取得註冊局資料庫中的每個已提交事務並將其逐步應用到DNS伺服器。內嵌有域註冊局的域命令的DNSSEC籤名可以通過確保例如註冊局資料庫總是表示在DNS中發布的內容的權威源，在維護最高級的數據完整性方面提供優勢。作為實現DNSSEC內嵌籤名的一部分，網絡可用和高性能籤名伺服器集群，例如，圖I和2中所示的，可以提供來籤名DNSSEC信息。已經發現其即使在最大的TLD的上下文中也有效，並且即使在服務來自需要數字籤名的客戶端的1000+同時連接吋，也會以高級數據完整性維護DNS傳播SLA』 S，並維護域註冊局響應時間SLA』 S。本發明的實施例可包括執行所述方法的系統，以及編碼有促使計算機執行所述方法的指令的計算機可讀存儲介質。例如，如圖12所示，像伺服器600，610和/或620這樣的伺服器系統包括至少ー個處理器、存儲器和電子通信設備(未示出)，其可配置為對例如在此描述的那些通過例如網際網路的網絡605接收的請求進行接收、識別、響應和/或行動。伺服器600，610和/或620中任一個可例如由在此進ー步描述的網際網路主機提供商、註冊商和/或註冊局來操作，並且可以與一般由網絡設備630代表的任何數量的遞歸DNS伺服器通信。如在此描述的那樣，遞歸伺服器630可為主機提供商、註冊商和/或註冊局操作伺服器600，610和620的域緩存DNS相關數據。請求更新域的DNS數據可通過各種系統(諸如例如計算機611，612)，通過可與(ー個或多個)行動裝置614、微微小區網絡設備615、移動計算機616或任何具有必備功能能力的其他具有網絡能力設備進行無線或其他通信的分離的伺服器613，例如從註冊商、DNS服務提供商或註冊者來發起。在此描述的各種通信、傳輸和相關功能可例如通過網絡605完成，並且諸如伺服器600，610和620這樣的伺服器系統執行的所述處理的結果可以根據已知技術而被顯示， 存儲和/或分配。網絡605可包括任何數量的通信組件，包括無線，蜂窩，衛星，光和/或其他類似通信鏈路。伺服器600，610和620以及計算機611，612可包括任何數量的處理器(未示出)，
其耦合到存儲設備，包括第一存儲器(未示出，典型地是隨機存取存儲器，或「RAM」)、第二存儲器(未示出，典型地是只讀存儲器，或「ROM」)。這兩種存儲設備可包括任何合適類型的計算機可讀介質，包括非暫時存儲介質，諸如快閃記憶體驅動，硬碟，軟盤，磁帶，例如CD-ROM盤的光介質，和/或磁光介質。還可使用海量存儲設備(未示出)以存儲程序、數據等等，並且典型地是次級存儲介質，例如比主存更慢的硬碟。將會意識到在海量存儲設備中保留的信息可以在合適的情況下以標準方法合併作為主存的一部分作為虛擬存儲器。特定的海量存儲設備，諸如⑶-R0M，還可單方向地向處理器傳遞數據。伺服器600，610和620和計算機611，612還可包括接ロ，其包括一個或多個輸入/輸出設備，諸如視頻監視器，軌跡球，滑鼠，鍵盤，麥克風，觸敏顯示器，傳感器讀卡器，磁帶或紙帶閱讀器，寫字板，指示筆，聲音或手寫識別器，或其他已知輸入設備，包括其他計算機。伺服器600，610和620以及計算機611，612可耦合到計算機或其他使用網絡連接的電子通信網絡605。網絡605可連接各種有線，光，電和其他已知網絡以在伺服器600，610和620，計算機611，612，獨立伺服器613，(ー個或多個)行動裝置614，微微小區網絡設備615，(ー個或多個)移動計算機616，遞歸伺服器630和任何其他具有類似功能的設備之間交換信息。具有這樣的網絡連接，可以考慮到伺服器600，610和620，和計算機611，612，和其中的處理器可在執行以上描述的方法步驟期間從網絡605接收信息，或可向網絡605輸出信息。以上描述的設備和物質對計算機硬體和軟體領域的技術人員所熟知，並且不需要単獨或詳盡地描述以被本領域技術人員所理解。以上描述硬體元素可以(通常臨時)配置為作為執行以上描述操作的ー個或多個模塊。此外，本發明的實施例進ー步包括計算機可讀存儲介質，其包括用於執行此處描述的各種計算機可執行操作的程序指令。該介質還可單獨地或組合地包括程序指令，數據文件，數據結構，表等等。介質和程序指令可以是那些專門為了本發明的目的設計和構造的，或者它們可以是計算機軟體領域技術人員可獲得的類型。計算機可讀存儲介質的示例包括磁介質，諸如快閃記憶體驅動，硬碟，軟盤，磁帶；光介質，諸如CD-ROM盤；磁光介質；和專門配置為存儲和執行程序指令的硬體設備，諸如只讀存儲器設備(ROM)和隨機存取存儲器(RAM)。程序指令的示例包括機器代碼(諸如由編譯器創建)以及包括高級代碼的文件(其可由計算機使用解釋器來執行)。以上給出的說明書僅是說明性的，並且不意味著是本發明所有可能的實施例，應用或修改的詳盡列表。因此，本發明所述的方法和系統的不同修改和改變將對本領 域技術人員是顯而易見的，沒有背離本發明的範圍和精神。雖然本發明已經結合具體實施例加以描述，但應當理解所要求保護的本發明不應當過度地限制為這樣的具體實施例。
權利要求
1.ー種DNSSEC籤名伺服器，配置為與至少ー個DNSSEC客戶端應用和多個數字籤名模塊進行交互，該DNSSEC籤名伺服器包括 處理器；和 包括計算機可讀代碼的存儲裝置，所述計算機可讀代碼當由處理器執行時使籤名伺服器作為權威伺服器以 從所述至少ー個客戶端應用接收籤名請求以籤名第一數據； 為所述第一數據確定激活的KSK和激活的ZSK中的至少ー個； 將所述第一數據發送到所述多個數字籤名模塊中的ー個； 從數字籤名模塊接收所述第一數據的經數字籤名的版本；以及 將經籤名的第一數據提供給所述客戶端應用。
2.根據權利要求I所述的伺服器，其中所述籤名伺服器進一歩配置為 接收作為相同籤名請求的部分的請求來籤名第二數據； 為所述第二數據確定激活的KSK和激活的ZSK中的至少ー個，其不同於用於所述第一數據的所述至少一個激活的KSK和/或激活的ZSK ； 將所述第二數據發送到所述多個數字籤名模塊中的ー個； 從數字籤名模塊接收所述第二數據的經數字籤名的版本；以及 將經籤名的第二數據提供給客戶端應用。
3.根據權利要求I所述的伺服器，其中所述第一數據包括DNS數據，所述數字籤名模塊配置為根據DNSSEC協議對DNS數據的特定部分進行籤名，而不是對整個區域籤名。
4.根據權利要求3所述的伺服器，其中所述籤名伺服器進一歩配置為提供額外的非DNSSEC數字籤名功能。
5.根據權利要求I所述的伺服器，其中所述籤名伺服器進一歩配置為 接收多個籤名請求作為單個請求分組的部分；以及 分析所述請求分組以識別具有彼此不同的激活的KSK、激活的ZSK和籤名協議中的至少ー個的不同籤名請求。
6.根據權利要求I所述的伺服器，其中所述至少一個激活的KSK和激活的ZSK基於包含在所述籤名請求中的TLD標識符確定。
7.根據權利要求6所述的伺服器，其中所述籤名伺服器進一歩配置為根據包含在所述籤名請求中的服務類型標識符從多個不同的數字籤名功能中區分請求的籤名功能,並根據所述服務類型標識符將非DNSSEC籤名請求路由到非DNSSEC數字籤名模塊。
8.根據權利要求I所述的伺服器，其中每個數字籤名模塊包括硬體安全模塊(HSM)，其在物理上與所述籤名伺服器的處理器分離，並配置為對由所述籤名伺服器提供的數據進行數字籤名。
9.根據權利要求8所述的伺服器，其中所述HSM包括多個根據別名標識符識別的密鑰，所述籤名伺服器進一歩配置為將用於DNS數據的KSK和ZSK中的至少ー個的別名標識符傳遞到所述數字籤名模塊，而不傳遞所述至少ー個KSK和ZSK到所述數字籤名模塊。
10.根據權利要求9所述的伺服器，其中所述籤名伺服器進一歩配置為定期檢查激活的KSK或ZSK的資料庫，根據從所述資料庫接收的信息確定在給定時間哪些別名標識符是激活的，其中傳遞到所述數字籤名模塊的別名標識符是激活的別名標識符。
11.根據權利要求9所述的伺服器，其中所述伺服器進ー步配置為根據所述至少ー個激活的KSK和/或激活的ZSK識別特定HSM以發送所述第一數據。
12.根據權利要求I所述的伺服器，其中所述籤名伺服器進一歩配置為處理關於在不同頂級域下的域的請求。
13.根據權利要求I所述的伺服器，其中所述籤名進ー步配置為處理關於由多個註冊商管理的至少兩個域 的請求。
14.根據權利要求I所述的伺服器，其中所述客戶端和所述籤名伺服器之間的通信通過雙向SSL執行。
15.根據權利要求I所述的伺服器，其中所述籤名進ー步配置為 為所述第一數據確定多於ー個的激活的密鑰和/或激活的算法； 將用於所述多於ー個的激活的密鑰和/或激活的算法的標識符發送到所述數字籤名模塊； 從所述數字籤名模塊接收所述第一數據的多個經數字籤名的版本；以及 將第一數據的所述多個經數字籤名的版本提供給所述客戶端應用。
16.根據權利要求I所述的伺服器，其中所述數字籤名模塊，響應於接收所述第一數據，從資料庫動態地加載用於所述第一數據的激活的KSK和激活的ZSK中的所述至少ー個。
17.—種由DNSSEC籤名伺服器對DNS信息進行加密的方法，所述DNSSEC籤名伺服器配置為與至少ー個DNSSEC客戶端應用和多個數字籤名模塊進行交互，所述方法包括 從所述至少ー個客戶端應用接收籤名請求來籤名第一數據； 為所述第一數據確定激活的KSK和激活的ZSK中的至少ー個； 將所述第一數據發送到所述多個數字籤名模塊中的ー個； 從所述數字籤名模塊接收所述第一數據的經數字籤名的版本；以及 將經籤名的第一數據提供給所述客戶端應用。
18.根據權利要求17所述的方法，進ー步包括 接收作為相同籤名請求的部分的請求來籤名第二數據； 為所述第二數據確定激活的KSK和激活的ZSK中的至少ー個，其不同於用於所述第一數據的所述至少一個激活的KSK和/或激活的ZSK ； 將所述第二數據發送到所述多個數字籤名模塊中的ー個； 從數字籤名模塊接收所述第二數據的經數字籤名的版本；以及 將經籤名的第二數據提供給所述客戶端應用。
19.根據權利要求17所述的方法，其中所述第一數據包括DNS數據，所述數字籤名模塊配置為根據DNSSEC協議對DNS數據的特定部分進行籤名，而不是對整個區域籤名。
20.根據權利要求19所述的方法，其中所述籤名伺服器進一歩配置為提供額外的非DNSSEC數字籤名功能。
21.根據權利要求17所述的方法，其中接收多個籤名請求作為單個請求分組的部分，所述方法進ー步包括 分析所述請求分組以識別具有彼此不同的激活的KSK、激活的ZSK和籤名協議中的至少ー個的不同籤名請求。
22.根據權利要求17所述的方法，其中所述至少一個激活的KSK和激活的ZSK基於包含在所述籤名請求中的TLD標識符確定。
23.根據權利要求22所述的方法，進ー步包括根據包含在所述籤名請求中的服務類型標識符從多個不同的數字籤名功能中區分請求的籤名功能，並根據所述服務類型標識符將非DNSSEC籤名請求路由到非DNSSEC數字籤名模塊。
24.根據權利要求17所述的方法，其中每個數字籤名模塊包括硬體安全模塊(HSM)，其在物理上與所述籤名伺服器的處理器分離，並配置為對由所述籤名伺服器提供的數據進行數字籤名。
25.根據權利要求24所述的方法，其中所述HSM包括多個根據別名標識符識別的密鑰，所述方法進ー步包括將用於DNS數據的KSK和ZSK中的至少ー個的別名標識符傳遞到所述數字籤名模塊，而不傳遞所述至少ー個KSK和ZSK到所述數字籤名模塊。
26.根據權利要求25所述的方法，進ー步包括定期檢查激活的KSK或ZSK的資料庫，根據從所述資料庫接收的信息確定在給定時間哪些別名標識符是激活的，其中傳遞到所述數字籤名模塊的別名標識符是激活的別名標識符。
27.根據權利要求25所述的方法，進ー步包括根據所述至少ー個激活的KSK和/或激活的ZSK識別特定HSM以發送所述第一數據。
28.根據權利要求17所述的方法，進ー步包括處理關於在不同頂級域下的域的請求。
29.根據權利要求17所述的方法，進ー步包括處理關於由多個註冊商管理的至少兩個域的請求。
30.根據權利要求17所述的方法，其中所述客戶端和所述籤名伺服器之間的通信通過雙向SSL執行。
31.根據權利要求17所述的方法，進ー步包括 為所述第一數據確定多個ー個的激活的密鑰和/或激活的算法； 將用於所述多於ー個的激活的密鑰和/或激活的算法的標識符發送到所述數字籤名模塊； 從所述數字籤名模塊接收所述第一數據的多個經數字籤名的版本；以及 將第一數據的所述多個經數字籤名的版本提供給所述客戶端應用。
32.根據權利要求17所述的方法，進ー步包括響應於接收所述第一數據，在所述數字籤名模塊動態地從資料庫加載用於所述第一數據的激活的KSK和激活的ZSK中的所述至少ー個。
全文摘要
描述了用於執行DNSSEC籤名的系統和方法，其中數字籤名操作可以由網絡可訪問籤名伺服器執行，所述伺服器配置為與分離的客戶端應用交互。示例的方法可以包括在籤名伺服器從戶端應用接收籤名請求以籤名第一數據。籤名伺服器可以為該第一數據確定激活的KSK和/或激活的ZSK。第一數據然後可以由籤名伺服器發送到數字籤名模塊，其可以包括，例如，硬體支持模塊或者軟體籤名應用。籤名伺服器可以從數字籤名模塊接收該第一數據的經數字籤名的版本，並將經籤名的第一數據提供給客戶端應用。
文檔編號H04L9/32GK102769529SQ20121020831
公開日2012年11月7日 申請日期2012年5月2日 優先權日2011年5月2日
發明者D·史密斯, D·德什潘德, J·古爾德, R·萊武 申請人:弗裡塞恩公司