解決網絡過載的問題的一個解決方法是在現有的DNS中加入動態負載平衡的特性。
隨著計算機網絡的應用的日益廣泛，在互聯網上的負載也變得日益擁擠，這經常導致服務器無法正常地響應，並且影響了一些應用程序的崩潰。而且，這種現象的發生是動態的。解決這個問題的一個方法是建造更加強大的服務器，而另外一個途徑就是將客戶請求分散到多個服務器上。後者是解決這個問題的一種巧妙的方法，通過這種方法實際上是一種平衡的藝術，可以避免一些服務器過於繁忙而另外的服務器非常空閒的狀態。跨服務器的需求分配技術成為網絡技術的一個重要課題。
我們來考慮這麼兩種情況：首先，每個TCP進程會消耗32比特的內存，這樣，一個有32MB內存的服務器從理論上支持100萬的連接。其次，在多個擁有同樣內容的服務器中，用戶總是喜歡根據他們自己的經驗（或者是一些監測數據）訪問一些服務負載較小的服務器，比如說，GetRight就可以選擇一個較佳的服務器進行FTP下載。但是，我們可以可以通過定期地監測服務器的狀態並將請求指向最佳服務器來實現請求的分配。這種在多個服務器中根據服務器負載動態定向請求的技術稱之為動態負載平衡。這個功能可以加入域名服務（DNS）中，而這是因為域名服務器本身就充當了解析客戶請求的主要責任，而具有這種特性的DNS稱為dlbDNS(dynamic load balance DNS)。在這裡，最佳服務器指的是通過一種排名算法的出最佳排名的服務器。
在這裡，我們將要解釋通過dlbDNS對DNS擴展所帶來的好處。首先，我們必須要考慮dlbDNS設計應該達到的性能：
（1）新的設計必須與原來的DNS應用兼容。
（2）該設計必須要易於配置。
（3）負載平衡必須快速而且有效。
（4）一個主機可以屬於多個組或者簇。
（5）對一個請求的響應應當動態地產生。
（6）對服務器的監控應當由不同的進程所產生。
（7）TTL的值應當設為最小以防止其他名字服務器的緩存的響應。
（8）最終的設計應當是一個通用性的名字服務器，可以被同時用於簡單的、反向的和動態的請求。
（9）對錯誤應當有所響應。
（10）負載平衡的過程對用戶來說是透明的。
負載平衡模型
有四種負載平衡平衡模型可供使用：首先，RFC1794描述了使用一個特別區域代理以從外部資源獲得信息的負載平衡方法，這樣，一個新的區域通過名字服務器被載入。這個方法的問題是大量的信息量，包括靜態的或者是可能需要分配的信息量，都在區域中進行循環地傳送。同時，這個方法也不支持根據被請求的名字所回應的動態創建的虛擬/動態域名。
第二個模型是通過一個專門的負載平衡服務器來解釋請求並將其指向一個最佳服務器。這種設計由負載服務器在內部使用虛擬的IP地址。而這種服務器的問題在於需要在被監控地服務器群中加入另外一台服務器而不是使用現有的資源。
第三個模型是通過一個遠程監視系統來監視不同服務器的性能，從而提供給DNS一個反饋。這個設計可以幫助解決無法直接觀測的系統問題，同時提供給用戶以訪問時間的測算。這種方式的問題就是在於需要依靠遠程網絡進行監視並且分發數據。
最後一種方案就是通過內部監視系統來監視服務器的性能，並且提供給DNS的反饋。這主要的優點就是易維護性和管理性，而且也沒有安全方面的問題。dlbDNS就是使用的這種方式。
負載平衡算法
最初，負載平衡只是為了允許DNS代理可以支持機器簇的概念，在這裡，這些機器的功能都是類似的或者相同的。而且，它並不需要特別關心選擇了哪台機器。這樣，負載就被平均地分配在一系列實際上並不相同的主機上。因為機器有著不同的配置和能力，這樣，我們就需要更加復雜的算法。
“循環算法A”可以以一種循環方式在服務器中平均的分配請求。但是，盡管這些請求是被動態地處理，對於不同的性能特點的忽視使這種算法的一個問題。
“負載平均算法A”可以根據服務器的負載分配請求。這個設計非常簡單而且也較為低廉。但是這種算法卻不能應付服務器在配置和潛力方面有差異的情況。
“排名算法A”基於如下所示的用戶的數目和負載平均的列表。這個算法是比較合理的，因為它根據最少的單個訪問以及較低負載平均來進行排名最佳主機的。這個算法在dlbDNS中確定最佳服務器的時候被使用。
WT_PER_USER = 100
USER_PER_LOAD_UN99v = 3
FUDGE = (TOT_USER - UNIQ_USER) * (WT_PER_USER/5)
WEIGHT = (UNIQ_USER * WT_PER_USER) + (USER_PER_LOAD_UN99v * LOAD) + FUDGE
在這個列表中，變量的名稱的含義如下：
TOT_USER: 登錄的用戶的總數
UNIQ_USERS: 登錄的不重復用戶的數目（比如說，用戶a和用戶b就是兩個不重復的用戶，而不管他們登錄了多少次）
LOAD: 最後一分鐘的負載平均乘100
WT_PER_USER: 每個用戶的負載量
FUDGE: 如果用戶多次登錄之後的修正參數
WEIGHT: 服務器的排名
dlbDNS的使用
首先，我們從Internet Software Consortium (http://www.isc.org/bind.Html)下載BIND8.1.2（在BIND8.1.2中就支持了dlbDNS的特性），在示例中DNS被安裝在dydns.cLinux.org上，在一個獨立的Linux工作站上進行測試。請看我們的配置：
在我們的配置中，由一個新的屬性稱為DNAME被加入來區分參加到動態負載平衡的主機。在我們上面這個配置中，我們可以看到，back1.dydns.clinux.org，back2.dydns.clinux.org和b.dydns.clinux.org被用來充當www1.dydns.clinux.org的動態負載，hack1.dydns.clinux.org，hack2.dydns.clinux.org和h.dydns.clinux.org被用來充當www2.dydns.clinux.org的動態負載。如下列表：
named.hosts.clinux
;
;
;named.hosts.wsu
; http://www1.cs.twsu.edu
www1 IN DNAME back1.dydns.clinux.org.
www1 IN DNAME back2.dydns.clinux.org.
www1 IN DNAME b.dydns.clinux.org.
服務器端的算法
以下是dlbDNS中的算法。如果一個服務器的請求是DNAME類型，那麼，服務器就會進行如下的一些動作：
1、確定在這個服務中參與的服務器的集合。
2、通過和每個服務器建立一個同步的非連接性的連接獲取每個參與的服務器的排名值。
3、根據返回的排名值，確定最佳服務器。
4、處理錯誤信息。
排名服務算法
一個排名服務運行在參與到動態負載平衡的每個服務器上，以下是算法：
1、從dlbDNS接收排名請求。
2、每一分鐘都對主機的排名進行計算，而不是在得到請求的時候才進行計算。因為回應時非常重要的一個因素。
3、確認主機排名是每分鐘都進行更新的。
4、處理錯誤情況，比如說dlbDNS在未等待主機回應的情況下關閉了UDP接口。
dlbDNS的好處
這個就不需要多說了，除了可以充分地利用資源之外，因為我們通過DNS來實現負載平衡，這樣FTP和TELNET之類的程序也可以使用dlbDNS。
發展方向
目前，在通過BIND的代碼中，gethostbyname系統將不能正常工作，這個問題可以通過一個主機和IP地址的列表的配置文件來解決。當然，我們希望由一個更好的解決方法。
第二，排名算法還不完善，算法還不能考慮處理器的數目，對CPU和內存的考慮會使得算法更加有效。
第三，在Linux服務器上，排名算法使用的是/proc文件結構中的文件，這樣只能說是動態平衡配置，應該還需要一個更加強大的設計。
備注：dlbDNS的源代碼可以從http://www.cs.twsu.edu/~hcvillia/acads/project/獲得。
3、確認主機排名是每分鐘都進行更新的。
4、處理錯誤情況，比如說dlbDNS在未等待主機回應的情況下關閉了UDP接口。
dlbDNS的好處
這個就不需要多說了，除了可以充分地利用資源之外，因為我們通過DNS來實現負載平衡，這樣FTP和TELNET之類的程序也可以使用dlbDNS。
發展方向
目前，在通過BIND的代碼中，gethostbyname系統將不能正常工作，這個問題可以通過一個主機和IP地址的列表的配置文件來解決。當然，我們希望由一個更好的解決方法。
第二，排名算法還不完善，算法還不能考慮處理器的數目，對CPU和內存的考慮會使得算法更加有效。
第三，在Linux服務器上，排名算法使用的是/proc文件結構中的文件，這樣只能說是動態平衡配置，應該還需要一個更加強大的設計。
備注：dlbDNS的源代碼可以從http://www.cs.twsu.edu/~hcvillia/acads/project/獲得。
