簡介
問題在於用戶無法知道DNS應答的來源是否正確或者是否包含正確的數據。只要稍微學習一下，甚至一個十幾歲的黑客都可以用錯誤數據來破壞DNS伺服器，而Web客戶機卻識別不出錯誤數據。這樣就帶來很大的麻煩，因為DNS經常被用作默認的認證系統。
例如，當一個用戶在瀏覽器上點擊一家報紙的網站時，他期望看到的網頁是那家報紙的。但是，DNS協定並不包含任何可以證明該網頁正確的機制，即該網頁確實是他期望的那家報紙的網頁。還會有一種更危險的情況出現，某些組織為了達到某種目的，把毫無防範的用戶引導到一個對該報紙進行批評、或者蓄意篡改該報紙內容甚至以誹謗的方式對事件進行錯誤報導的Web伺服器上。
為了解決這一問題，IETF正在著手在DNS協定里加入安全擴展協定，也就是所謂的域名系統的安全協定（DomainNameSystemSECurity，DNSSEC）。
DNS的產生
在DNS之前，每個新的主機都必須添加到位於斯坦福研究院的網路信息中心（StanfordReseachInstitute'sNetworkInformationCenter，SRI-NIC）的中央存儲設備里。直到90年代初，一直由該中心負責維護這些信息。SRI-NIC經常發布主機信息的檔案，Arpanet（Internet的前身）上的所有主機就拷貝這些檔案。這種機制在Internet上只有少量主機時是可以運作的，但是隨著Internet的增長，這種機制就不穩定了。
此外，這種機制中域名管理的結構非常簡單。因此，每一個在SRI-NIC註冊的主機名都必須是惟一的。例如，那時侯在Internet上，無論在哪裡都不可能有2個主機同時叫做www。後來，SRI-NIC終於讓位給DNS。
DNS對Internet最重要的貢獻之一就是它可以在全球範圍內把可以識別的主機名惟一地映射成IP位址，即所謂的前向映射。DNS還有一些其他功能，包括反向映射（IP位址到主機名的解析）、郵件交換信息（給一個給定主機或者域確定一個郵件交換器）以及規範命名（系統化的命名方案）。
結構和缺陷
DNS採用層次化結構，使得主機名可以惟一化。DNS的結構為反向樹結構，由樹葉走向樹根就可以形成一個全資格域名（FullyQualifiedDomainName，FQDN），每個FQDN是惟一的。在樹中，由根到葉給出主機名查詢結果，以便於找到屬於這台主機的IP位址。對於反向映射也有類似的樹存在，在樹中檢索查詢IP位址的目的是為了找到屬於這個IP位址的主機名或者FQDN。
反向樹的頂端是DNS的根，通常以“.”表示，並且是FQDN中的最後一個字元。根下面的第一級劃分為大組，例如組織類（org）、工商類（com）和教育類（edu）等等。再下面一級通常表示一個特定的直接在org、edu和com域下面的組織或者公司。例如isc.org或者vix.com。“isc”和“vix”也都被認為是域名。
這種劃分域名的方式使得每個主機都可以在其歸屬的域（或者子域）內有惟一的定義。這樣本地管理員就可以管理（增加、刪除或者改動）DNS主機名和地址。DNS可以進行主機名本地管理的能力提供了巨大的靈活性和可擴展性。
DNS所做的另一項改進是提高每個域中包含信息的可用性。除了主伺服器外，其餘的都成為二級或從伺服器。每個域都有一個以上的從伺服器。這些從伺服器負責檢驗主伺服器的數據更新，如果檢測到有一個數據更新，從伺服器就傳送域的數據，也就是所謂的域傳遞。
每個域都有一個序列號，當主伺服器上的域數據更新時，就要調整這個序列號。這種調整使得在伺服器上檢測到數據更新變得很容易。而能夠同時擁有一個以上域備份的能力可以冗餘分配負載，使數據非常可靠。
DNS高效率的設計同時也帶來了負面影響，那就是眾多的安全性漏洞。例如，當一個遠程系統連線了一個應用程式後，該應用程式使用IP位址向DNS伺服器查詢DNS域名，如果返回的域名被該應用程式所認可，那么該遠程系統也具備訪問許可權。
實際上，一個惡意使用者能夠非常輕鬆地搶占到一個很小的IP位址空間，同時在DNS伺服器上註冊，獲取這些IP位址的反向映射。
密碼簽名
由於DNS協定的局限，IETF已成立了DNSSEC工作組，目的是在現有的協定上增添附加的DNSSEC部分，從而解決DNS缺乏安全性的問題。伯克利Internet域名保護協定（BerkeleyInternetNameDaemon，BIND）8.2中包含了一些DNSSEC的功能。
DNSSEC的目標就是為在DNS內部的信息同時提供許可權認證和信息完整性（參看附圖）。DNSSEC通過密碼可以實現這些目標。
附圖顯示的是一對DNS詢問和應答過程的示例，一個沒有採用DNSSEC協定，另一個採用了DNSSEC協定。注意，在採用DNSSEC協定的例子中，應答信息中不僅包含了驗證信息所需的簽名和關鍵字，而且包含了原始的詢問。這就是所謂的“事務處理和請求認證”。這種方式向詢問者保證所得到的應答確實是針對其原始問題的。
DNSSEC主要依靠公鑰技術對於包含在DNS中的信息創建密碼簽名。密碼簽名通過計算出一個密碼hash數來提供DNS中數據的完整性，並將該hash數封裝進行保護。私/公鑰對中的私鑰用來封裝hash數，然後可以用公鑰把hash數譯出來。如果這個譯出的hash值匹配接收者剛剛計算出來的hash樹，那么表明數據是完整的。
不管譯出來的hash數和計算出來的hash數是否匹配，對於密碼簽名這種認證方式都是絕對正確的，因為公鑰僅僅用於解密合法的hash數，所以只有擁有私鑰的擁有者可以加密這些信息。因此，對於任何系統，開發保護私鑰的公鑰技術是至關重要的。DNSSEC工作組定義的RFC2541中解釋了這個問題。
DNSSEC的缺點
標記和校驗DNS數據顯然會產生額外的開銷，從而影響網路和伺服器的性能。簽名的數據量很大，這就加重了DNS對Internet骨幹網以及一些非骨幹連線的負擔。產生和校驗簽名也占用了很多CPU的時間。有時候，不得不把單處理器的DNS伺服器換成多處理器的DNSSEC伺服器。簽名和密鑰占用的磁碟空間和RAM容量達到它們表示的數據所占容量的10倍。同時資料庫和管理系統也不得不進行相應的升級和擴容。
使用DNSSEC還有若干種直接的損失。相對於老的、只有DNS的軟體，DNSSEC軟體又龐大又複雜，許多軟體還很新，需要進行實際操作和測試。DNSSEC還沒有和Internet的迅速發展同步，仍然有一些疑點，可能需要進一步檢查。
開發DNSSEC也有一定的風險。謹慎的選擇是在DNSSECRFC提升為標準狀態後再等一兩年。到1999年12月，只有ISC的BIND8.2完全使用了TSIG並部分使用了DNSSEC。其他銷售商（包括微軟）在未來版本中都將使用各種形式的TSIG。ISC的BIND9.0將於2000年第一季度發表，它完全採用了DNSSEC。
工作進展
對於DNSSEC在可操作方面的工作正在進行之中，比如com管理者如何正確地簽發公鑰。為了解決這個問題，一個新的協定即將出現。此外，在同時發生的套用中支持多個公/私鑰對也是必要的，但是如何實現還有待進一步的工作。如果一個私鑰被破壞，那么就需要取消，可是目前還沒有一個設備可以檢測出來有錯誤的密鑰。還有私鑰的安全問題，該密鑰從表面上講是全球Internet企業的密鑰，但是目前有關伺服器的管理正在變化之中。
儘管DNSSEC還處在開發過程中，但是任何依賴於Internet的組織都應該把DNSSEC作為系統安全結構里的關鍵部件，因為DNS協定會因為惡意使用而遭到破壞，只有通過DNSSEC強大的加密技術才可以給所有方面的DNS提供整體的授權。
