如果你有一個很受歡迎的Web站點，你會發現當請求的連接數增加時，服務器的響應延時也會隨之增加。雖然你可以增加RAM、升級處理器、使用更快的驅動器及總線,這在短期內會有一定的幫助，但最終會發現一臺服務器無法完成需要的任務。
使用多臺服務器平衡負載是一個不錯的想法，你可以在你的服務器池中隨意增加多臺服務器來提高服務器的性能和增強網絡的穩定性。如果你的服務器池中有多臺服務器，當一臺down機後，其他服務器可以接替它的工作，繼續提供服務而不至於造成服務中斷。
通過使用RR-DNS（Round-Robin Domain Name System）可以實現平衡負載的功能，向一個主機名發出的入站請求可以被轉發到多個IP地址上。
在BIND9中實現此功能就向添加一條A記錄那麼簡單。舉例說，如果我們向somode.com區域文件中加入下面行便可實現：
www 60 IN A 220.181.11.124
60 IN A 220.181.11.125
當然你還可以根據需要加入更多服務器。這樣如果有人請求解析www.somode.com時將有一半的機率解析到220.181.11.124上，而另一半會解析到220.181.11.125上。
然而，使用RR-DNS方法實現負載平衡也會帶來一些問題：
第一，域名服務器是一個分佈式系統，是按照一定的層次結構組織的。當用戶將域名解析請求提交給本地的域名服務器，它會因不能直接解析而向上一級域名服務器提交，上一級域名服務器再依次向上提交，直到RR-DNS 域名服務器把這個域名解析到其中一臺服務器的IP 地址。可見，從用戶到RR-DNS 間存在多臺域名服務器，而它們都會緩衝已解析的名字到IP 地址的映射,這會導致該域名服務器組下所有用戶都會訪問同一Web 服務器，出現不同Web 服務器間的負載不平衡。爲了保證在域名服務器中域名到IP 地址的映射不被長久緩衝，RR-DNS 在域名到IP 地址的映射上設置一個TTL(Time To Live)值，過了這一段時間，域名服務器將這個映射從緩衝中淘汰。當用戶請求，它會再向上一級域名服務器提交請求並進行重新映射。這就涉及到如何設置這個TTL值，若這個值太大，在這個TTL 期間，很多請求會被映射到同一臺Web 服務器上，同樣會導致負載不平衡。若這個值太小，例如是０，會導致本地域名服務器頻繁地向RR-DNS提交請求，增加了域名解析的網絡流量，同樣會使RR-DNS 成爲系統中一個新的瓶頸。
第二，用戶機器會緩衝從名字到IP 地址的映射，而不受TTL 值的影響，用戶的訪問請求會被送到同一臺Web 服務器上。由於用戶訪問請求的突發性和訪問方式不同，例如有的人訪問一下就離開了，而有的人訪問可長達幾個小時，所以各臺服務器間的負載仍存在傾斜（Skew）而不能控制。假設用戶在每個會話中平均請求數爲20，負載最大的服務器獲得的請求數額高於各服務器平均請求數的平均比率超過百分之三十。也就是說，當TTL 值爲0 時，因爲用戶訪問的突發性也會存在着較嚴重的負載不平衡。
第三，系統的可靠性和可維護性不好。若一臺服務器失效，會導致將域名解析到該服務器的用戶看到服務中斷，即使用戶按“Reload”按鈕，也無濟於事。系統管理員也不能隨時地將一臺服務器切出服務進行維護，如進行操作系統和應用軟件升級，這需要修改RR-DNS 服務器中的IP 地址列表，把該服務器的IP 地址從中劃掉，然後等上一段時間，等所有域名服務器將該域名到這臺服務器的映射淘汰，和所有映射到這臺服務器的客戶機不再使用該站點爲止。
RR-DNS方法只是一個簡單的負載平衡方案，如果你有更高要求，可以研究LVS集羣（IPVS和KTCPVS、TCPHA），實現基於IP的負載均衡和基於內容的負載均衡。