在發現經常訪問的網站出現宕機或者誤入某些非常下流網站的原因是由于域名系統(DNS)被污染而造成的。域名系統緩存污染并屬于不經常發生的問題，但問題是一旦出現真正發生的情況，就可能會導致互聯網上大部分區域陷于停頓狀態。解決這一潛在威脅的辦法是什么?答案就是域名系統安全擴展(DNSSEC)。

域名系統通常是這樣的情況下被污染的。DNS是互聯網地址名單的管理者。在它的幫助下，你不需要自己輸入出類似“http：//209.85.135.99/”這樣一個谷歌擁有的眾多IPv4地址之一來訪問對應的網站，只要簡單地輸入“http：//www.google.com”就可以達到相應的目的。但是，你的瀏覽器是如何確認“209.85.135.99”就屬于谷歌的正確地址呢?就本身而言，它是做不到這一點的。它需要依賴于DNS，并且，在這里沒有什么好抱怨的，普通DNS系統里沒有內置任何措施，來確保返回給瀏覽器的相關信息是正確有效的。

而DNSSEC的作用就是通過要求網站利用DNS服務器來對域名和對應的網絡IP地址進行驗證的方式來防止DNS緩存被污染。為了確保信息不受到破壞，DNSSEC利用數字簽名和公鑰技術來對交換信息進行了加密。由于需要破壞流行網站的DNS信息才能獲取加密信息，這種防護措施反過來又讓黑客對DNS服務器的攻擊更難實現。

從7月15日開始，作為主DNS服務器的13臺互聯網根域名服務器已經實現了對DNSSEC的支持。到現在，在互聯網全部294個頂級域(TLD)中已經有55個開始支持DNSSEC。這里面包括了所有非盈利性組織使用的.org域，教育機構使用的.edu域。并且，威瑞信已經決定從2011年初起為.net域提供DNSSEC支持。

對于我們中的大多數人來說，這個層次的變化真得無所謂。我們并不需要呼叫根域名服務器或者頂級域來對域名進行解析。實際上，現在切換到DNSSEC給我們帶來的影響才剛剛開始。在10月18日，康卡斯特成為第一家部署DNSSEC的主要互聯網服務供應商。因此，如果你現在想使用DNSSEC的話，就已經沒問題了。不論你是否屬于康卡斯特的用戶，都可以將自己的DNS服務器指向IP地址設置為75.75.75.75和75.75.76.76。關于操作的詳細說明，你可以觀看康卡斯特提供的DNSSEC說明視頻。如果你想了解為什么說使用DNSSEC是一個好主意的話，可以登錄新建立的安全域名系統使用指南網站，上面提供了全面詳細的說明資料。

所以，如果說DNSEC是一個非常好的主意的話，為什么不是所有人都已經做到了呢?這個么，你看，如同任何互聯網的重大調整，在應用DNSSEC到舊的程序和硬件上時，可能會出現問題。

最主要的問題就是一些路由器、交換機和防火墻不能有效處理DNSSEC的數據包。DNS流量使用的是用戶數據報協議(UDP)，在通常情況下，DNS用UDP數據包的大小是在512字節之內。因此，網絡上的很多軟件和硬件都默認拒絕超過512字節的任何UDP數據包。不幸的是，DNSSEC的數據包總是大于512字節。

在某些系統中，這會導致DNS出現故障。而在其它系統中可能會導致故障并轉移到傳輸控制協議(TCP)中。與UDP相比使用TCP的缺點就是，占用的帶寬大得多。盡管可能不是什么大問題，但對于企業網絡的管理者來說，這會導致潛伏期明顯增加。并且，沒人喜歡互聯網速度變慢。

此外，當客戶搜索一家不存在的網站時，一些互聯網服務供應商和DNS服務器會對DNS答復信息進行重寫，將他們重定向到經過定制的搜索頁面上。舉例來說，我使用OpenDNS的原因就是，它的DNS查詢速度比我的互聯網服務供應商更快。但是，如果我輸入的域名不存在，它將會返回一個OpenDNS的搜索頁面。在DNSSEC下使用OpenDNS這么做時，會發生什么情況?我不知道，但我有種工作情況不會很正常的不好感覺。

順便提一下，在DNS安全管理方面，OpenDNS已經提供了其它選擇：DNSCurve。DNSCurve將如何實現與DNSSEC協同工作呢?答案是不可能。它們試圖利用截然不同的方法來實現DNS安全。對于用戶來說，這可能就意味著，不管其它地方使用的是什么安全措施，你依然可以使用DNS，但如果大家使用的不是相同技術的話，在安全方面就不會獲得任何保障。

就個人來看，我認為大家目前能做的最好情況，就是更新內部DNS軟件和固件到最新的DNSSEC兼容版本。我們還可以了解上游的DNS是否按照域名系統運行分析研究中心為非網絡管理員用戶提供的指南部署了DNSSEC，為了簡單起見，你也可以選擇運行Java應用程序，快速得到清晰明確的確定答案。

如果發現使用的ISP沒有使用DNSSEC的話，提醒他們盡快部署。DNSSEC是未來發展的趨勢，ISP部署使用的越早，獲得的安全性就越高。