DNSSEC的選擇：Yes還是No？
2023-05-18 中國教育網絡
Geoff Huston APNIC首席科學家
互聯網早期的特點是技術的不斷更新。例如，路由協議接二連三地出現和消失，傳輸技術處于不斷變化的狀態，我們用來與新興數字環境交互的設備正在變化，我們使用的應用程序也在變化。因此有些令人驚訝的是，至少有一個協議在互聯網四十多年的發展中保持相對穩定，那就是域名系統（DNS）和相關的DNS解析協議。
也許我們可以將傳輸協議UDP（用戶數據報協議）和TCP（傳輸控制協議）也放入同一類協議中。在互聯網協議中，它們肯定是最古老的協議之一，并且今天仍在大量使用。這是對這些協議基本設計的肯定，雖然網絡和它的使用者已經增長了十億倍甚至更多，但這些協議基本上保持不變。
通常引用的DNS規范是兩個RFC，RFC1034，“域名——概念和設施”，以及RFC1035，“域名——實現和規范”，它們都發表于1987年11月。然而，這兩個核心規范只是一個相當大規范集合的冰山一角。涉及DNS的RFC協議大概有292個。這意味著聲稱DNS在這四十年期間基本不變有點牽強，但無論如何，DNS的基本原理是不變的。這些額外的292個RFC說明了我們在這四十年中花了大量的時間和精力來修補DNS協議的邊邊角角！
在DNS發生的這些變化中，我必須提名DNS安全框架——域名系統安全擴展（DNSSEC）作為最重要的DNS創新。DNSSEC將數字簽名添加到DNS資源記錄，允許客戶端解析程序確認DNS應答的真實性。你可能會認為，隨著人們對互聯網攻擊的廣泛認識，讓用戶驗證從DNS查詢收到的響應的任何行為都將被視為向前邁出的一大步，我們都會主動要求使用它。
但現實是，人們對DNSSEC的熱情并不高。遞歸DNS解析程序的管理員并不愿意添加解析步驟來請求DNS記錄的數字簽名并對其進行驗證，同時在網絡終端節點很少有DNS存根解析程序提供類似的功能。在簽名側，將DNSSEC簽名添加到DNS域的做法同樣不受歡迎。準確計算互聯網中所有域名的數量實際上是不可能的，因此精確計算有DNSSEC簽名的域名百分比同樣是一個具有挑戰性的問題。DNSSEC社區一致認為，大約只有10%的DNS域名是經過DNSSEC簽名的。
人們為什么對DNSSEC的反應如此缺乏熱情？
DNSSEC已經存在了足夠長的時間，所以對DNSSEC的無知不能成為借口。那些不在自己的管理域上簽名的域管理員肯定有自己的理由。
對于是否啟用DNSSEC簽名和驗證，似乎有很多不確定性。一些解析器運營商似乎已經接受了DNSSEC，包括由Google和Cloudflare運營的大型開放解析服務網絡。另一方面，有許多解析器不執行DNSSEC驗證。APNIC實驗室對DNSSEC驗證率的測量表明，如果已簽名的DNS名稱的DNSSEC簽名無法驗證，大約30%的用戶將不會加載URL（圖1）。
圖1 DNSSEC驗證比例
那么，DNSSEC是個好主意嗎？或者僅僅是事倍功半的努力？為什么亞馬遜和微軟沒有為域名部署DNSSEC協議？為什么美洲銀行網站、匯豐銀行網站沒有為其網站域名添加DNSSEC簽名？相關在線服務用戶的安全性完全依賴于域名可驗證的真實性，你可能會認為，能夠驗證域名到IP地址的DNS映射將是保證其在線服務真實性不可避免的第一步。然而，許多域名并沒有DNSSEC簽名。
我認為，沒有一個明確的答案來回答這個問題，即，使用DNSSEC來簽署域名是否是一個好主意。雖然DNSSEC提供了一個更有彈性和更可靠的DNS服務，讓用戶可以信任他們收到的DNS解析答案與當前域名權威域的內容完全匹配。但這是有代價的，在DNS域中添加DNSSEC簽名和在DNS響應中驗證這些簽名的增量成本是否值得，是一個需要討論的問題。
讓我們從“是”與“否”兩個方面來看看是否要對DNS域名進行DNSSEC簽名。
DNSSEC值得嗎？“不！”
我們很容易將DNSSEC看作是DNS中的又一個錯誤設計。對于DNS域管理員，DNSSEC又增加了一組域管理任務，包括添加密鑰管理、定期密鑰更新、密鑰滾動以及與父域/委托域（parent zone/delegated zones）的密鑰協調。鑒于即使是簡單的域委托或者域配置在大部分DNS服務器中都會被錯誤配置，那么將加密密鑰和數字簽名管理元素添加到管理任務集中，只會增加那些選擇DNSSEC對其域進行簽名的人無意中出現域名故障的可能性。
對全域進行簽名是首先要考慮的一個問題。全域簽名在較小的域中可能很簡單，但對于較大的域，即使將整個域作為一個文本文件的快照映像進行簽名也是一項巨大的挑戰。許多較大的DNS域都會不斷更新，而整個DNS域的簽名操作要求對更新進行批處理（凍結已簽名的域內容，直到下一次計劃的更新和簽名操作）。
這種操作實踐可能不適用于具有大量客戶端的大型DNS域，因為這些客戶端對更改條目的及時性有不同的需求。許多DNS域利用了動態簽名的優勢，該區域的DNS服務器和DNSSEC簽名前端分別運行，如果查詢請求DNSSEC憑據，則將響應從DNS服務器傳遞到DNSSEC簽名前端，并將數字簽名記錄作為最后步驟添加到DNS響應中。
NSEC記錄（Next Secure Record，下一個安全記錄）為DNSSEC添加了新的挑戰。通常NSEC響應會列出與名稱相關的所有資源記錄，包括請求域名記錄不存在時，域中排列的下一個記錄名稱。NSEC記錄可以通過負向查詢（不存在的記錄）對域中內容進行枚舉攻擊。這給某些DNS運營商帶來了一些問題，他們出于商業或安全方面的原因希望將域內容保密。
這個問題導致了NSEC3記錄的開發，它使用基于散列值的域標簽排序來避免枚舉攻擊，但散列函數增加的復雜性比實際情況好很多，因為在當前的計算能力下，破解這個散列函數是可行的。最近擬議的NSEC5記錄將增加更多的復雜性對抗區域枚舉的脆弱性風險，但這一提議尚未引起廣泛關注。
還有一個問題，就是如何在DNSSEC簽名的區域保障服務的健壯性。傳統的方法是使用許多與主服務器配置相同的方式運行的輔助服務器，它們可以通過共享當前DNS域配置文件的副本來實現這一點。
在使用DNSSEC的條件下，共享主服務器已簽名的DNS域文件的副本是最簡單的方法，輔助服務器不需要知道該DNS域的區域簽名密鑰（ZSK）以及DNS域的密鑰簽名密鑰（KSK）的私鑰信息。但是，如果使用前端動態簽名器，則所有這些簽名前端都需要配置ZSK私鑰。
如果所有這些域名記錄簽署都由同一個實體操作，那相對簡單；但如果區域管理員使用不同的實體來操作輔助域名服務器系統，那么就需要將ZSK公鑰集合放入域的DNSKEY（DNS Public Key，域名公鑰）記錄中。這樣就會增加DNSKEY記錄的大小，而DNSSEC響應記錄大小是DNSSEC的主要問題之一，大型DNS響應記錄會影響DNS的可靠性和性能。
最早的UDP協議上的DNS響應記錄大小為512字節。添加DNSSEC數字簽名會導致DNS響應大小超過此限制，因此DNS查詢程序需要使用EDNS（DNS擴展機制）擴展來表示它們處理大型UDP響應的能力。
但是DNSSEC可能會導致響應記錄超過IP報文最大傳輸單元（MTU）的限制（1420字節的IPv4報文或1400字節負載的IPv6報文），從而需要使用IP分片進行報文傳輸。但是IP分片會讓請求者暴露于DNS緩存中毒攻擊的風險，并且在IPv6協議下可能需要重傳報文，導致更大的時間延遲。
另一種方法是截斷響應轉為TCP協議傳輸。但是TCP協議需要花費多個傳輸往返時延（RTT）的時間來建立握手和傳輸數據，同時并不是所有的客戶端都支持TCP協議下的DNS，這會帶來更大的不可靠性。
然而，花費在處理大型DNSSEC響應報文上的額外時間并不是唯一的問題，DNSSEC的驗證功能也需要額外的時間。為了驗證DNSSEC記錄的真實性，客戶端需要沿著簽名鏈一直向上驗證到根域的簽名者，這意味一個DNSSEC記錄的驗證需要產生大量的DNS查詢。
如果不進行解析結果的緩存，則需要將每個父域的DNSKEY和DS（Delegation Signer，委托簽名者）記錄組合起來進行驗證，這將帶來無法克服的時間損失。大多數終端系統不直接執行DNSSEC驗證。他們依賴DNS解析器來代表他們執行DNSSEC驗證，并且默認信任（implicitly trust）解析器以適當的完整性級別執行此操作。但這里帶來的問題是，在終端主機和驗證解析器之間的中間人攻擊仍然可能有效——終端主機沒有驗證DNS響應，因此無法檢測響應是否為真實響應或是否已被篡改。
以上所有問題都說明了DNSSEC在設計或操作上并不簡單。在錯誤發生的時候，要糾正的地方很多，而容錯的地方很少。這增加了DNS的脆弱性。
還有一個棘手的問題——DNSSEC保護你免受什么威脅？最初的教科書上的答案是保護解析器不受所謂的“卡明斯基攻擊（Kaminsky attack）”，這種攻擊將惡意數據注入遞歸解析器的緩存中。DNSSEC當然可以提供針對這種攻擊的保護，但僅限于有限的情況下。正如我們已經觀察到的，DNSSEC可以保護遞歸解析器，但是不驗證DNSSEC記錄的客戶端存根解析器仍然像以前一樣容易受到攻擊。
因此，這不是一個全面解決問題的辦法。如果DNS響應未能通過DNSSEC驗證，DNS將不會通知客戶端“正確”響應可能是什么。它只是保留無法驗證的響應，并將其留給客戶端決定下一步要做什么。
DNSSEC反應的成本是否與威脅的性質相稱？從負面的角度來看，DNSSEC還不成熟。它并非安全性和DNS功能的完美結合，而是一種相當笨拙的調整，以一種不舒服的方式放置在DNS之上。DNSSEC的增量成本和脆弱性遠遠超過了從一個相當模糊的威脅模型中減輕風險的潛在好處。
但也許我夸大了“不”的理由。DNSSEC的采用對用戶和整個互聯網都有非?，F實的潛在好處。讓我們看看這個話題的另一面。
DNSSEC值得嗎？“是的！”
互聯網安全的總體情況是相當糟糕的。當用戶識別屏幕上的URL，點擊它，并相信呈現的網站是用戶打算訪問的真正服務，這中間的路徑依賴于相當多的盲目信任。我們相信DNS將域名映射到的IP地址是真實的，相信路由系統將IP數據包傳遞到“正確的”終端，相信屏幕上的網站名字是你打算訪問的服務，相信TLS（安全傳輸層協議）連接是真實的，相信你從未見過的人永遠不會撒謊，而這只是一大堆盲目信任中的幾個例子。
這些關系和行為中不透明的信任都是以誠信為基礎的，無法被審計，也不能被曝光。我們只能希望每個人的行為都是出于最好的意圖。但當我們把越來越多的個人和社會功能放在一個由計算機連接的世界里時，我們對互聯網的完整性的依賴也越來越大，而無論是高級黑客、犯罪團伙，都具備顛覆互聯網基礎設施運行的能力，并可以造成相當大的破壞。
那我們現有的強大的名稱基礎設施和TLS證書難道沒有任何意義嗎？在我看來，DNSSEC存在的理由在于現有互聯網名稱基礎設施信任模式的弱點。
現有的信任結構基于域名的X.509公鑰證書，它試圖在域名、域名持有人和公鑰/私鑰對之間建立聯系。如果客戶端使用域名作為DNS查詢的關鍵字，并使用響應結果的IP地址連接到服務器，那么只要服務器能夠證明它知道與這個域名相關的私鑰，域名證書就能向客戶端保證它已經到達域名持有人提供的與這個域名相關的服務站點。
在這種形式的認證中，用于訪問該服務的IP地址其實是不重要的。TLS協議的安全握手過程向客戶提供了服務的公鑰、域名證書和用服務的私鑰生成的“謎題”，向客戶提供了它已到達真實服務的保證?？蛻舳瞬⒉皇呛唵蔚匦湃芜@些提供的信息，它也被預先配置了一組可信的證書頒發者（認證機構）的公鑰集合。只要客戶端能夠驗證所提供的域名證書是由這些受信任的證書頒發者之一頒發的，那么它就能夠相信服務站點的真實性，認為它“屬于”這個域名。
這里的問題是，實際情況比設想的要糟糕的多。每個客戶端有數百個受信任的證書頒發者，每一個頒發者都能夠為任何域名頒發數字證書。如果任何一個證書頒發者被入侵并頒發假證書，那么這些假證書與所有其他合法頒發的真證書之間是無法區分的。只要一個證書頒發者被包括在客戶信任的頒發者集合中，那么客戶就無條件地信任這個頒發者，并無條件地接受其頒發的所有證書是真的。
因此，我們有一個“最薄弱環節”：域名持有者使用的證書頒發者的工作有多好并不重要。重要的是一組證書頒發者中最不可靠的那一個的工作質量；只要有一個證書頒發者被破壞了，那么它就會被迫為任何域名頒發假證書。
還有其他一些因素也破壞了對域名證書框架的信任。第一個因素是價格的侵蝕。人們一直在努力降低證書的價格，理由是為在線服務提供安全保障不應該是少數人可以獲得的昂貴的奢侈品，而應該是普遍可以負擔的商品。
例如，Let's Encrypt運營的自動門戶提供的免費域名證書已經將這一點推向了極端。這些免費服務只需要申請人證明他們可以將指定記錄添加到相關的域名區域文件中，或在域名的網站空間內生成一個URL頁面。這些免費證書的合法性等同于任何其他域名證書，而入侵網站或者DNS域服務器修改文件就可以導致假域名證書的頒發。
第二個因素是，盡管證書撤銷可以減輕假證書帶來的風險，但證書撤銷不再被普遍支持。在證書撤銷過程中，證書頒發者會定期公布一個不應再被信任的證書序列號列表。當客戶驗證一個證書時，它應該查閱證書頒發機構（CA）的證書撤銷列表（CRL），檢索這個CRL并通過其簽名驗證其內容，然后在這個列表中查找該證書的序列號。
如果在CRL中找不到它，說明該證書沒有被撤銷，或者更準確地說在CRL創建（一般是過去幾天）時，它還沒有被撤銷。撤銷證書的數量越多，CRL就越大。對于一個大型CA來說，提供所有廢止證書的完整列表似乎是一種過度的回答，特別在查詢者只是想知道單個證書的廢止狀態的情形下。另外，生成CRL并不是對CA的一項強制性要求。CA可以選擇定期發布CRL，也可以選擇發布增量CRL更新，或者根本就不發布CRL！由于這些原因，終端客戶在建立TLS會話時通常不使用CRL。
取而代之的是，我們要使用在線證書狀態協議（OCSP）。OCSP會在證書中插入一個OCSP URL，客戶端連接到這個URL，并向其發送要檢查的序列號，URL的響應給出該證書已被撤銷或者未被撤銷。然而，OCSP實際情況也很糟糕。在客戶端與CA聯系的過程中，OCSP存在隱私問題，因為CA通過OCSP請求的來源知道客戶端使用該證書的身份，并知道客戶端在何時使用該證書。
每次客戶端需要訪問證書的OCSP數據時，不僅有隱私泄漏的問題，而且還存在生成OCSP請求和等待響應的額外時間的性能問題。OCSP有時不是一個請求，而有可能會是整個證書驗證鏈上的多個請求，這會導致更大的性能消耗，而查詢結果還不是當前的撤掉狀態，僅僅是CRL建立或更新時的撤銷狀態。
然后，我們轉向了“裝訂式OCSP（Stapled OCSP）”，即服務器代表客戶端進行OCSP檢查，并將簽名的OCSP響應與證書一起發送。但如果證書在生成CRL時沒有被撤銷，那么，如前所述，OCSP報告的狀態是好的，這對證書中已經包含的信息來說沒有任何增加。
如果證書被撤銷，那么CA就是在說，這個證書不應該被使用。如果是這樣的話，那么服務器為什么要把證書和OCSP狀態傳達給客戶，并讓客戶決定不繼續進行TLS連接？為什么服務器不應該簡單地立即終止TLS連接？換句話說，服務器為什么要把一個被撤銷的證書傳遞給客戶以達到TLS連接嘗試失敗的必然結果？
證書撤銷是否值得努力？Chrome瀏覽器已經得出結論：不值得。對于那些以虛假借口頒發的有效證書，或者被泄漏的密鑰，我們又能做些什么呢？事實是我們什么也做不了。這里沒有通用的解決方案，每一種撤銷證書的方法都代表著某種程度的妥協。
我們可以接受具有高注冊成本的長壽命證書，但前提是我們能夠支持強大而快速的撤銷機制，而這一點至今仍是一個難以實現的目標。CRL和OCSP不是即時反應，盡管它們都可以減少因私鑰被破壞而產生的漏洞的影響時間，但是CRL和各種類型的OCSP都有一些明顯的魯棒性問題。
我們可以沿著Let's Encrypt的道路前進，只使用由高度自動化程序生成的短期證書（這里的“短期”仍然有90天之長?。?。鑒于它們的壽命很短，撤銷并不是一個大問題，而且可以考慮更短的證書壽命。
但是，如果我們沿著這條短期證書的道路前進，那么為什么還要使用X.509封裝證書呢？為什么不把在DNS中包裝OCSP響應的方法再往前推一步，完全不使用X.509封裝，而把整個公鑰基礎設施放到DNS中呢？我們當然可以朝這個方向發展，但要做到這一點，需要將DNSSEC應用到DNS中來保護這些信息。
現在可以總結一下證書提供的安全框架和DNSSEC提供的安全框架之間的本質區別。
域名證書框架使用分布式信任框架，證書可以由任何CA簽發。這個框架中每個證書的健壯性基于系統中最薄弱CA的安全性，而這已經在過去引發了一系列安全問題。相比之下，DNSSEC的信任框架是基于單一的私鑰，即根區的KSK。
域名證書可由發行人撤銷，但撤銷狀態檢查已被證明在操作上具有挑戰性。實際的應對措施是將簽發的證書的有效期限制在幾個月內，并免去撤銷檢查。底層的DNS框架被設計為迫使DNS信息的持有者定期檢查他們的緩存信息的有效性。在DNSSEC框架中，數小時或數天的緩存壽命都是可行的。
域名證書是對域名授權狀態的一個獨立證明，而DNSSEC是DNS本身的一部分，安全證書是DNS名稱的一個屬性。
在我看來，使用DNSSEC的理由在于，DNSSEC是一種更統一的向域名添加可信憑證的方式，其中憑證的屬性與名稱本身的屬性密切相連，而通過域名證書證明這種密切聯系的挑戰則要大得多。DNSSEC的問題在于DNS協議被設計成處理按需輕量級查詢/響應的交易集合，沒有考慮如何有效地處理大的DNS協議載荷，也沒有考慮如何在查詢中指定相互關聯的關系（如按需驗證）。
現在呢？
不要小看一個強大而穩定的域名基礎設施的作用。由于證書發放行為對網絡的可信度造成了很大的沖擊，現有的證書透明度、HTTP公密鑰綁定（HPKP）以及證書權威認證（CAA）等認證機制并沒有得到很好的應用?，F在的問題在于，我們到底是否愿意為域名公鑰基礎設施投入更多內容，還是要換一種方式，徹底拋棄這種由第三方提供的安全性。
從理論上來說，將一個域的安全性證書放入DNS，并把域名持有人的公鑰當作域名的一個屬性，這樣才能避免通過第三方（域名證書）對域名進行安全驗證。目前看來，DNS中的域名密鑰（DANE，基于DNS的域名身份認證協議）方案是我們對這個問題的最好回應，這意味著我們需要有一個可信任的DNS，用戶可以驗證DNS數據是否真實，而DNSSEC是我們目前知道的實現這一目標的唯一方法。
在TLS中使用DANE協議，可以采取OCSP裝訂的方式，將服務器的公鑰響應作為DANE資源記錄，然后將DNSSEC簽名和相關的DNSSEC驗證響應作為鏈式擴展數據塊一起裝訂。如果客戶端直接使用DNS，那么這些記錄將出現在DNS查詢響應的數據集合中，但在使用OCSP裝訂的情況下，服務器將收集這些數據并在TLS握手過程中傳遞給客戶端。
DANE方法的優點是在本地證書自治域內支持更短的證書時間管理。執行OCSP裝訂的服務器受到DNS本地緩存生命周期（TTL）的限制，并需要在這個時間間隔內刷新DNS數據。同時，因為是服務器而不是客戶端裝訂數據，客戶端的身份和查詢的域名不會暴露給DNS服務器。
但是，前文討論的DNS報文過大的問題仍然沒有解決。那么，我們可以避免大的DNSSEC響應報文，同時繼續使用DNSSEC嗎？令人驚訝的是，至少在某種程度上答案是“可以”。目前我們在DNSSEC簽名中常用的算法是RSA算法。RSA是一種基于素數運算的加密算法，使用模運算和可變長度的密鑰進行加密和解密。較短的RSA密鑰在加密和解密方面更有效，但不那么魯棒。較長的密鑰使用起來更昂貴，但針對破解攻擊提供了更好的魯棒性。
這種使用越來越大的RSA密鑰的趨勢導致人們試圖擺脫素數密碼學，并尋找其他數學函數，包括橢圓曲線。橢圓曲線函數ECDSAP-256允許所有的DNSSEC資源記錄，即RRSIG（Resource Record Signature，資源記錄簽名）、NSEC(3)、DNSKEY和DS記錄，這些記錄在大多數情況下都在512字節以下（密鑰滾動期間例外）。所以如果我們使用橢圓曲線加密算法，就可以避免大型DNSSEC響應。
根據目前的估計，使用P-256曲線的ECDSA算法強度與帶有3072位密鑰的RSA大致相當。256位的ECDSA密鑰比3072位的RSA密鑰短得多，同樣，ECDSA的簽名也比RSA的簽名短得多。這一點很重要，因為DNSSEC同時存儲和傳輸密鑰和簽名。雖然橢圓曲線加密算法可以讓DNSSEC簽名的響應在UDP上以非分片的報文進行傳輸，但執行DNSSEC驗證所需的時間問題仍然存在。DNS協議的按需“及時（just in time）”模式是20世紀80年代有限的計算和通信環境的產物。
而在一個計算和通信資源豐富的環境中，可以考慮一種新的服務模式：預先計算好響應報文的內容，“以備（just in case）”客戶可能會問到這些信息，這就是使用DNS鏈擴展模型背后的想法。服務器將簽名后的DNSKEY和DS資源記錄的完整集合與域名權威服務器的記錄簽名結合起來，以備客戶端要求提供與DNS響應相關的DNSSEC憑證。在這種情況下，服務器可以立即響應整個集合，客戶端可以立刻驗證簽名，而不需要再執行新的DNS查詢。
使用UDP報文來傳輸這種DNSSEC數據并不適合，而且可能會導致拒絕服務（DoS）攻擊的發生。在使用DNSSEC鏈式擴展的背景下，使用DNS-over-TLS（DoT）或DNS-over-HTTPs（DoH）進行傳輸，在TLS證書交換中裝訂屬性以方便使用DANE作為CA證書固定的措施，都具有更大的意義。
我們還需要完善DNS錯誤代碼以明確標識DNSSEC驗證失敗的情形，這可以防止現有SERVFAIL（解析失?。╁e誤代碼下的解析器重新查詢行為。我們也正在努力使終端主機具備DNSSEC驗證能力，這樣終端主機就不會依賴主機和其DNS解析器之間不受信任的（和脆弱的）連接。而且我們不要忘記，DNS中的緩存是非常有效的。DNSSEC中的數字簽名的緩存方式與地址記錄的緩存方式相同，因此，如果相關的資源記錄已經被保存在本地緩存中，那么經過驗證的DNS名稱的解析就不會有額外的時間成本。
如果沒有一個安全和可信賴的互聯網名稱基礎設施，互聯網的前景看起來就沒有那么好。DNSSEC并沒有提供一個完整的答案，但它看起來確實是一個強大的、安全和可信任的互聯網的基本要素之一。也許這就是我們采用它的充分理由。我們可以而且應該在該技術上做出努力，讓DNSSEC更加有效，使用起來更加方便快捷。但我們不應該讓“完美（perfect）”成為“好（good）”的敵人。
等待一個“更好的（better）”DNSSEC是沒有意義的。我們將無限期地等待，而攻擊數字基礎設施的問題則將持續存在。另一個選擇是，簡單地使用我們手頭的東西，并充分運用經驗進一步努力，以加強DNS并建設更強大的互聯網基礎設施。
總結
應該用DNSSEC簽署你的域名嗎？答案在于了解你的保護目標。如果保護域名映射到IP地址對你來說至關重要，那么DNSSEC在某種程度上無疑可以做到這一點。如果保護DNS域免受干擾和操縱很重要，那么DNSSEC在某種程度上也可以做到這一點。這里的限定條件是，DNSSEC無法防止任何第三方對DNS響應的偽造攻擊，但它可以檢測何時發生此類攻擊，并在這種情況下拒絕DNS響應。
其次，DNSSEC對DNS信息真實性的保證依賴于客戶端（或客戶端的代理）使用DNSSEC進行驗證。如果客戶端沒有驗證DNSSEC簽名的DNS響應，那么客戶端就無法提供更好的安全性。
第三，客戶端需要能區分DNSSEC驗證失敗和其他的DNS解析錯誤原因。當DNS解析框架使用默認的SERFAIL錯誤代碼來返回DNSSEC驗證錯誤狀態時，DNS系統會花費更多時間尋找能提供答案的服務器。
最后，只要客戶端主機中的DNS解析器不直接執行DNSSEC驗證，那么當響應從驗證解析器發送到客戶端時，客戶端仍然容易受到DNS欺騙的攻擊。
我們可以采用更宏觀的視角，提出DNSSEC應該部署在哪里以及為互聯網環境帶來哪些好處的問題。在廣泛采用執行服務器身份驗證的安全傳輸會話之前，互聯網應用程序和服務的基本常見假設是，如果客戶端將數據包地址發送到“正確”的目標地址，那么它將獲得“正確”響應。在這樣的框架內，保護從名稱到IP地址的映射很重要。如果攻擊者可以以客戶端無法檢測到的方式提供備用IP地址，那么客戶端將認為替代IP地址是該服務的“正確”服務交付點。
網絡環境在很大程度上消除了這種非常幼稚的假設，特別是瀏覽器在要求服務器執行TLS握手方面更加嚴格，要求服務器以域名證書和簽名數字對象的形式提供證書，允許客戶端使用第三方信任錨來驗證該服務確實是客戶端正在尋求的命名服務。在這種環境下，名稱到IP地址的真實性不再是關鍵。
如果服務器能夠提供適當的證書，那么客戶端將接受服務器為服務的真正實例，而不考慮用于到達該服務的IP地址。如果DNSSEC所能做的只是保護從名稱到IP地址的映射，那么它所提供的服務在今天的服務環境中基本上是不合時宜的。
也許所有選擇不對其域名進行DNSSEC簽名的網站都是明智的，可以避免當DNSSEC簽名被封裝到DNS響應時帶來的問題，也避免了客戶端花費額外的時間來驗證這些DNSSEC證書。如果有假的網站試圖來劫持域名，TLS協議的握手過程都會檢測到這種攻擊嘗試。
雖然域名PKI（Public Key Infrastructure，公鑰基礎設施）代表了當今互聯網安全框架的基礎，但這并不意味著它在所要實現的目標上總是有效的。這個PKI中高度分布式的信任模式，以及缺乏CA固定的有效手段，意味著任何一個被破壞的CA都可以破壞任何服務的真實性，而且這種行為基本上不會被終端客戶注意到。
缺乏一個有效的證書撤銷模式意味著當一個證書不應該被信任時，大多數客戶端根本不會進行任何形式的撤銷狀態檢查。企業環境往往要求主機增加本地維護的受信任CA集合，這反過來又意味著基于主機的惡意軟件可以通過向本地受信任CA集添加流氓CA來創造額外的攻擊載體。證書系統已經采取了一系列的措施，如通過HPKP記錄、CAA記錄和證書透明度來鎖定CA，但這些舉措并不是對這些問題的有效對策。
我們怎樣才能在域名PKI框架中解決這些問題？怎樣才能提高現有PKI的穩健性？正是在這種情況下，DNS重新進入了視野，DNSSEC也隨之成為解決方案。通過使用DANE，DNS可以讓客戶端只加載受信任CA發布的證書，解決CA固定的問題?；蛘逥NS可以讓TLS只加載應該使用的終端實體證書（或其公鑰），以解決CA固定和證書撤銷的問題。
或者，DNS可以提供TLS應該使用的自簽名證書或公鑰，這樣就繞過所有現有的域名PKI驗證檢查。雖然DANE選項可以解決TLS的缺點，但它們也存在一些新的問題。為了信任這些DANE記錄，當務之急是使用DNSSEC簽名DNS中的這些DANE記錄，并要求TLS客戶端直接執行DNSSEC驗證。
但考慮到在TLS握手中加入任何形式的DNS查詢都是完全不現實的，我們需要使用OCSP所使用的信息“裝訂（stapling）”方法。在這種方法中，額外的信息和所有應該用來驗證這些信息的數據都被加載到TLS握手中。我們需要考慮如何應對從TLS服務器握手數據包中刪除這些信息的降級攻擊，目前提議的方法是，要求在簽署的終端實體證書中用一個標志位來進行DANE驗證。
如果這是DNSSEC的唯一用途，并且我們改變了DNS客戶端的默認查詢設置，不在傳統DNS查詢中繼續使用DNSSEC，那么情況就會好得多。如果DNSSEC僅被用于傳統DNS查詢/響應交易之外的證書相關裝訂記錄查詢，那么DNSSEC的缺陷將被避免，而TLS握手過程中的證書驗證性能將不會受到任何重大影響。
因此，有了DANE，我們知道需要做什么來解決TLS現有域名證書框架的漏洞問題，而這種DANE方法必然包括在非查詢模式下使用DNSSEC。但是，我們會往那個方向前進嗎？我們會看到集成了DANE和DNSSEC裝訂信息的TLS實現嗎？或者我們愿意繼續容忍現有PKI框架的漏洞，因為利用這些漏洞的成本比在TLS中加入新的驗證框架和在DNS空間中加入DNSSEC更容易？
我認為，這個問題是DNSSEC未來前景背后的關鍵問題。
作者：Geoff Huston（APNIC首席科學家）
來源：APNIC
節譯：楊望
責編：項陽
特別聲明：本站注明稿件來源為其他媒體的文/圖等稿件均為轉載稿，本站轉載出于非商業性的教育和科研之目的，并不意味著贊同其觀點或證實其內容的真實性。如轉載稿涉及版權等問題，請作者在兩周內速來電或來函聯系。
相關閱讀
DNSSEC原理、配置與部署(二)2011/07/25
DNSSEC原理、配置與部署2011/06/27
混合加密機制降低計算復雜度2011/04/18
刪不掉的“鬼”域名2012/04/27
DNS拒絕服務攻擊與對策2015/03/05
頂層DNS服務器延遲測量問題2014/09/11
DNS調配出口實踐2014/05/30
DNS異常殃及5億網民 專家：我們得有自己的“根”2014/01/23
DNSSEC原理、配置與部署2011/06/27
混合加密機制降低計算復雜度2011/04/18
刪不掉的“鬼”域名2012/04/27
DNS拒絕服務攻擊與對策2015/03/05
頂層DNS服務器延遲測量問題2014/09/11
DNS調配出口實踐2014/05/30
DNS異常殃及5億網民 專家：我們得有自己的“根”2014/01/23
一起關注互聯網發展、互聯網技術、互聯網體系結構……
在教育部科技司領導下，中央電化教育館組織實施了教育信息化教學應用實踐共同體項目...
工作要點聚焦：教育信息化、網絡安全……都怎么干？
投稿、轉載或合作，請聯系：eduinfo#cernet.com (請將#替換為@)
版權所有：中國教育和科研計算機網網絡中心 CERNIC,CERNET
京ICP備15006448號-16 京網文[2017]10376-1180號 
京公網安備 11040202430174號
![京網文[2017]10376-1180號](/images/indexnew/www1024.jpg){kind=link}
關于假冒中國教育網的聲明 | 有任何問題與建議請聯絡：Webmaster@cernet.com