SLB负载均衡和DNS协议
SLB負載均衡和DNS協議
- SLB 負載均衡
- 負載均衡原理
- 負載均衡的組成
- 健康檢測
- HTTP/HTTPS監聽健康檢查機制
- 健康檢測中域名的設置
- TCP監聽健康檢查機制
- 健康檢查狀態對請求轉發的影響如下：
- 網絡流量路徑說明
- 入網流量路徑
- 出網流量路徑
- SLB使用實踐
- 監聽配置
- 選擇轉發策略
- DNS
- DNS基本概述
- DNS工作流程
- 分布式、層次數據庫
- DNS層次結構
- DNS查詢步驟
- DNS解析器
- DNS查詢類型
- DNS緩存
- DNS緩存的工作流程
- DNS緩存方式
- DNS報文
- 報文段首部
- 問題區域
- 資源記錄部分
- DNS安全
- DNS防火墻
- 參考文獻
SLB 負載均衡
負載均衡（Server Load Balancer，下文簡稱 SLB）的引入，可以降低單臺云服務器 ECS（下文簡稱 ECS）出現異常時對業務的沖擊，提升業務的可用性。同時，結合彈性伸縮服務，通過動態調整后端服務器，可以快速對業務進行彈性調整（擴容或縮容），以快速應對業務的發展。
負載均衡原理
**負載均衡CLB（Classic Load Balancer)**是將訪問流量根據轉發策略分發到后端多臺云服務器（ECS實例）的流量分發控制服務。負載均衡擴展了應用的服務能力，增強了應用的可用性。
負載均衡通過設置虛擬服務地址，將添加的同一地域的多臺ECS實例虛擬成一個高性能和高可用的后端服務池，并根據轉發規則，將來自客戶端的請求分發給后端服務器池中的ECS實例。
負載均衡默認檢查云服務器池中的ECS實例的健康狀態，自動隔離異常狀態的ECS實例，消除了單臺ECS實例的單點故障，提高了應用的整體服務能力。此外，負載均衡還具備抗DDoS攻擊的能力，增強了應用服務的防護能力。
負載均衡的組成
- 負載均衡實例 （Instances）：一個負載均衡實例是一個運行的負載均衡服務，用來接收流量并將其轉發給后端服務器，至少添加一個監聽(Listeners)和兩臺ECS實例。
- 監聽(Listeners):監聽客戶端的請求并將其轉發給后端服務器，監聽也會對后端服務器進行健康檢查。
- 后端服務器（Backend Servers）：后端服務器是一組接收前端請求的ECS實例，可以單獨添加ECS實例到后端服務器池；
健康檢測
負載均衡通過健康檢測來判斷后端服務器（ECS實例）的業務可用性。健康檢查機制提高了前端業務整體可用性，避免了后端ECS異常對總體服務的影響。
開啟健康檢測時，當后端某臺ECS健康檢測出現異常時，負載均衡會自動將新的請求轉發到其他健康檢測正常的ECS上；當ECS恢復正常運行時，負載均會會將其自動恢復到負載均衡服務中。
負載均衡在用集群部署，LVS集群或者Tengine集群內相關的節點服務器同時承載著數據轉發和健康檢測的職責。
Ps：
-
LVS集群：Linux Virtual Server,可以實現LINUX平臺下的簡單負載均衡，LVS采用三層結構：負載調度器、服務器池、共享存儲。
-
Tengine集群：Tengine是由淘寶網發起的Web服務器項目。它在Nginx的基礎上，針對大訪問量網站的需求，添加了很多高級功能和特性；
HTTP/HTTPS監聽健康檢查機制
針對七層（HTTP或HTTPS協議）監聽，健康檢查通過HTTP HEAD探測來獲取狀態信息；
檢查機制如下：
- Tengine節點服務器根據監聽的健康檢測配置，像后端的向后端ECS的內網IP+【健康檢查端口】+【檢查路徑】發送HTTP HEAD請求（包含設置的【域名】）；
- 后端ECS收到請求后，根據相應服務的運行情況，返回HTTP狀態碼；
- 如果在【響應超時時間】之內，Tengine節點服務器沒有收到后端ECS返回的信息，則認為服務無響應，判定健康檢查失敗；
- 如果在【響應超時時間】之內，Tengine節點服務器成功接收到后端ECS返回的信息，則將該返回信息與配置的狀態碼進行比對。如果匹配則判定健康檢查成功，反之則判定健康檢查失敗；
健康檢測中域名的設置
當使用HTTP方式進行健康檢查時，可以設置健康檢查的域名，但并非強制選項。因為有些應用服務器會對請求中的host字段做校驗，即要求請求頭中必須存在host字段。如果在健康檢查中配置了域名，則SLB會將域名配置到host字段中去，反之，如果沒有配置域名，SLB則不會在請求中附帶host字段，因此健康檢查請求就會被服務器拒絕，可能導致健康檢查失敗。綜上原因，如果您的應用服務器需要校驗請求的host字段，那么則需要配置相關的域名，確保健康檢查正常工作。
TCP監聽健康檢查機制
針對四層TCP監聽，為了提高健康檢查效率，健康檢查通過定制的TCP探測來獲取狀態信息：
1、SLB服務器根據監聽的健康檢查配置，向后端ECS的內網IP+【健康檢查端口】發送TCP SYN數據包；
2、后端ECS收到請求后，如果相應端口正在正常監聽，則會返回SYN+ACK數據包；
3、如果在【響應超時時間】之內，LVS節點服務器沒有收到后端ECS返回的數據包，則認為服務無響應，判定健康檢查失敗；并向后端ECS發送RST數據包中斷TCP連接；
4、在【響應超時時間】之內，LVS節點服務器成功收到后端ECS返回的數據包，則認為服務正常運行，判定健康檢查成功，而后向后端ECS發送RST數據包中斷TCP連接；
健康檢查狀態對請求轉發的影響如下：
- 如果目標ECS的健康檢查失敗，新的請求不會再分發到相應ECS上，所以對前端訪問沒有影響；
- 如果目標ECS的健康檢查成功，新的請求會分發到該ECS上，前端訪問正常；
- 如果目標ECS存在異常，正處于健康檢查失敗時間窗，而健康檢查還未達到檢查失敗判定次數（默認為三次），則相應請求還是會被分發到該ECS，進而導致前端訪問請求失敗;
業務流程如下所示：
網絡流量路徑說明
傳統型負載均衡CLB作為流量轉發服務，將來自客戶端的請求通過CLB集群轉發至后端服務器，后端服務器再將響應通過內網返回給CLB。
入網流量路徑
1、TCP/UDP協議和HTTP/HTTPS協議的流量都需要經過LVS集群進行轉發；
2、LVS集群內的每一臺節點服務器均勻地分配海量訪問請求，并且每一臺節點服務器之間都有會話同步策略，以保證高可用；
- 如果相應的CLB實例服務端口使用的是四層協議（TCP或UDP），那么LVS集群內每個節點都會根據CLB實例的策略，將其承載的服務請求按策略直接分發到后端ECS服務器；
- 如果相應的CLB實例服務端口使用的是七層HTTP協議，那么LVS集群內每個節點會先將其承載的服務請求均分到Tengine集群，Tengine集群內的每個節點再根據CLB策略，將服務請求按策略最終分發到后端ECS服務器；
- 如果相應的CLB實例服務端口使用的是七層HTTPS協議，與上述HTTP處理過程類似，差別是在按策略將服務請求最終分發到后端ECS服務器前，先調用Key Server進行證書驗證及數據包加解密等前置操作;
出網流量路徑
CLB和后端ECS之間是通過內網進行通信的；
-
如果ECS僅僅處理來自CLB的請求，可以不購買公網帶寬（ECS、公網IP、彈性公網IP、NAT網關等);
-
如果需要直接通過后端ECS對外提供服務，或后端ECS有訪問外網的需求，那么需要相應的配置或購買ECS、公網IP、彈性公網IP、NAT網關等服務;
總體原則，流量從哪里來就從哪里出去；
- 通過CLB進入的流量在CLB上限速或計費，僅收取出方向流量費用，入方向流量不收取（在未來可能會改變），CLB到ECS之間是阿里云內網通信，不收取流量費用。
- 來自彈性公網IP或NAT網關的流量，分別在彈性公網IP或NAT網關上進行限速或計費。如果在購買ECS時選擇了公網帶寬，限速/計費點在ECS上。
- CLB僅提供被動訪問公網的能力，即后端ECS只能在收到通過CLB轉發來的公網的請求時，才能訪問公網回應該請求，如后端ECS希望主動發起公網訪問，則需要配置或購買ECS公網帶寬、彈性公網IP或NAT網關來實現。
- ECS公網帶寬（購買ECS時配置）、彈性公網IP、NAT網關均可以實現ECS的雙向公網訪問（訪問或被訪問），但沒有流量分發和負載均衡的能力
SLB使用實踐
業務架構設計：
內網環境下，不支持多可用區，只看圖例的單邊即可；
SLB 在公網環境下的典型業務架構如上圖所示。基于多可用區特性，當主可用區出現異常時，SLB 會自動將流量切換到備可用區。
監聽配置
SLB支持創建多種協議監聽，按照轉發策略，將前端的業務請求轉發到后端的多種邏輯服務器集，配置SLB服務需要關注如下的要點：
- 并非只要 Web 網站就必須使用 HTTP 協議。大部分沒有特殊 HTTP 要求的 Web 網站，使用 TCP 監聽 80 端口就可以滿足業務需求。
- SLB 集群采用 LVS 和 Tengine 實現。其中 4 層監聽（TCP/UDP）經過 LVS 后直接到達后端服務器，而 7 層監聽（HTTP/HTTPS）經過 LVS 后，還需要再經過 Tengine 轉發，最后達到后端服務器，由于比 4 層多了一個處理環節。因此，7 層監聽的性能相對要差一些。
后端服務器集模式
SLB 后端服務器支持按 3 種邏輯創建服務器集。要點如下：
| 后端服務器 | 支持 | 不支持 | 無限制 | 創建監聽時的默認映射服務器集 |
| 虛擬服務器組 | 支持 | 支持 | 無限制 | 有更大的靈活性 |
| 主備服務器組 | 支持 | 支持 | 2 臺 | 只能在 TCP/UDP 監聽上使用 |
建議
- 按業務邏輯創建不同的虛擬服務器組，然后創建相應的監聽與之對應。
- 無論創建何種服務器集合，均結合 SLB 多可用區特性，同時加入位于不同可用區的服務器，以實現跨可用區容災。
- 設置過多轉發規則會增加業務維護的復雜度，建議盡量精簡策略條目。
選擇轉發策略
權重代表相應服務器所承載的業務的相對占比，而非絕對值。當前 SLB 支持 3 種轉發策略，其使用場景及要點如下：
| 加權輪詢（WRR） | 按比重輪流分配新增連接。 | ●根據后端 ECS 規格的不同，配置相應的權重。 ●如果是長連接業務，可能會導致老服務器的連接數持續增加， 而新加入服務器的連接數相對非常低，造成負載不均的假象。 |
| 加權最小連接數（WLC） | ●在 SLB 服務端，實時統計與后端 ECS 已建立的 ESTABLISHED 狀態連接數，來評估相應服務器的負載情況。 ●按權重比例，將新增連接分配給活動連接數少的服務器，最終盡可能使服務器的已建立連接數與其權重成正例。 | 當前暫未實現新增服務器的過載保護或緩沖機制。所以，如果業務并發非常高，可能會導致新增服務器連接數陡增，對業務造成影響。建議新增服務器時，逐步調高權重。 |
| 輪詢（RR） | 按順序逐一分發新增連接。 | 必須手工確保后端 ECS 的業務承載能力一致。 |
DNS
因特網上的主機和人類一樣，可以使用多種識別方式進行標識。互聯網上主機的一種標識方法是使用它的 主機名(hostname) ，如 www.baidu.com等。但是這是我們人類的記憶方式，路由器不會這么理解，路由器喜歡定長的、有層次結構的 IP地址。
路由器喜歡的是 IP 地址進行解析，我們人類卻便于記憶的是網址，那么路由器如何把 IP 地址解析為我們熟悉的網址地址呢？這時候就需要 DNS 出現了.
DNS 的全稱是 Domain Name System,DNS ，它是一個由分層的 DNS 服務器（DNS server）實現的分布式數據庫；它還是一個使得主機能夠查詢分布式數據庫的應用層協議。DNS 服務器通常是運行 BIND(Berkeley Internet Name Domain) 軟件的 UNIX 機器。DNS 協議運行在 UDP 之上，使用 53 端口。
DNS基本概述
當你在瀏覽器中輸入www.xxexplore.com/index.htm會經歷什么過程：
- 同一臺用戶主機上運行著 DNS 應用的客戶端；
- 瀏覽器從上述 URL 中抽取出主機名 www.xxexplore.com ，并將這臺主機名傳給 DNS 應用的客戶端；
- DNS 客戶向 DNS 服務器發送一個包含主機名的請求；
- DNS 客戶最終會收到一份回答報文，其中包含該目標主機的 IP 地址；
- 一旦瀏覽器收到目標主機的 IP 地址后，它就能夠向位于該 IP 地址 80 端口的 HTTP 服務器進程發起一個 TCP 連接；
DNS提供了以下的重要服務：
- 主機別名(host aliasing)，有著復雜的主機名的主機能夠擁有一個或多個其他別名，比如說一臺名為 relay1.west-coast.enterprise.com 的主機，同時會擁有 enterprise.com 和 www.enterprise.com 的兩個主機別名，在這種情況下，relay1.west-coast.enterprise.com 也稱為 規范主機名，而主機別名要比規范主機名更加容易記憶。應用程序可以調用 DNS 來獲得主機別名對應的規范主機名以及主機的 IP地址；
- 負載分配(load distribution)，DNS 也用于冗余的服務器之間進行負載分配。繁忙的站點例如 cnn.com 被冗余分布在多臺服務器上，每臺服務器運行在不同的端系統之間，每個都有著不同的 IP 地址。由于這些冗余的 Web 服務器，一個 IP 地址集合因此與同一個規范主機名聯系。DNS 數據庫中存儲著這些 IP 地址的集合。由于客戶端每次都會發起 HTTP 請求，所以 DNS 就會在所有這些冗余的 Web 服務器之間循環分配了負載；
DNS工作流程
假設運行在用戶主機上的某些應用程序（如 Web 瀏覽器或郵件閱讀器） 需要將主機名轉換為 IP 地址。這些應用程序將調用 DNS 的客戶端，并指明需要被轉換的主機名。用戶主機上的 DNS 收到后，會使用 UDP 通過 53 端口向網絡上發送一個 DNS 查詢報文，經過一段時間后，用戶主機上的 DNS 會收到一個主機名對應的 DNS 回答報文。因此，從用戶主機的角度來看，DNS 就像是一個黑盒子，其內部的操作你無法看到。但是實際上，實現 DNS 這個服務的黑盒子非常復雜，它由分布于全球的大量 DNS 服務器以及定義了 DNS 服務器與查詢主機通信方式的應用層協議組成。
DNS 最早的設計是只有一臺 DNS 服務器。這臺服務器會包含所有的 DNS 映射。這是一種集中式的設計，這種設計并不適用于當今的互聯網，因為互聯網有著數量巨大并且持續增長的主機，這種集中式的設計會存在以下幾個問題：
- 單點故障(a single point of failure)，如果 DNS 服務器崩潰，那么整個網絡隨之癱瘓；
- 通信容量(traaffic volume)，單個 DNS 服務器不得不處理所有的 DNS 查詢，這種查詢級別可能是上百萬上千萬級；
- 遠距離集中式數據庫(distant centralized database)，單個 DNS 服務器不可能 鄰近 所有的用戶，假設在美國的 DNS 服務器不可能臨近讓澳大利亞的查詢使用，其中查詢請求勢必會經過低速和擁堵的鏈路，造成嚴重的時延；
- 維護(maintenance)，維護成本巨大，而且還需要頻繁更新；
分布式、層次數據庫
首先分布式設計首先解決的問題就是 DNS 服務器的擴展性問題，因此 DNS 使用了大量的 DNS 服務器，它們的組織模式一般是層次方式，并且分布在全世界范圍內。沒有一臺 DNS 服務器能夠擁有因特網上所有主機的映射。相反，這些映射分布在所有的 DNS 服務器上。
大致來說有三種 DNS 服務器：根 DNS 服務器、 頂級域(Top-Level Domain, TLD) DNS 服務器 和 權威 DNS 服務器 。
DNS層次結構
- 根 DNS 服務器 ，有 400 多個根域名服務器遍及全世界，這些根域名服務器由 13 個不同的組織管理。根域名服務器的清單和組織機構可以在 https://root-servers.org/ 中找到，根域名服務器提供 TLD 服務器的 IP 地址；
- 頂級域 DNS 服務器，對于每個頂級域名比如 com、org、net、edu 和 gov 和所有的國家級域名 uk、fr、ca 和 jp 都有 TLD 服務器或服務器集群。所有的頂級域列表參見 https://tld-list.com/ 。TDL 服務器提供了權威 DNS 服務器的 IP 地址；
- 權威 DNS 服務器，在因特網上具有公共可訪問的主機，如 Web 服務器和郵件服務器，這些主機的組織機構必須提供可供訪問的 DNS 記錄，這些記錄將這些主機的名字映射為 IP 地址。一個組織機構的權威 DNS 服務器收藏了這些 DNS 記錄；
DNS查詢步驟
通常情況下，DNS 的查找會經歷下面這些步驟：
一旦 DNS 查找的步驟返回了 example.com 的 IP 地址，瀏覽器就可以請求網頁了；
DNS解析器
進行 DNS 查詢的主機和軟件叫做 DNS 解析器，用戶所使用的工作站和個人電腦都屬于解析器。一個解析器要至少注冊一個以上域名服務器的 IP 地址。DNS 解析器是 DNS 查找的第一站，其負責與發出初始請求的客戶端打交道。解析器啟動查詢序列，最終使 URL 轉換為必要的 IP 地址。
DNS 遞歸查詢和 DNS 遞歸解析器不同，該查詢是指向需要解析該查詢的 DNS 解析器發出請求。DNS 遞歸解析器是一種計算機，其接受遞歸查詢并通過發出必要的請求來處理響應。
DNS查詢類型
DNS 查找中會出現三種類型的查詢。通過組合使用這些查詢，優化的 DNS 解析過程可縮短傳輸距離。在理想情況下，可以使用緩存的記錄數據，從而使 DNS 域名服務器能夠直接使用非遞歸查詢；
1、遞歸查詢：在遞歸查詢中，DNS 客戶端要求 DNS 服務器（一般為 DNS 遞歸解析器）將使用所請求的資源記錄響應客戶端，或者如果解析器無法找到該記錄，則返回錯誤消息。
2、迭代查詢：在迭代查詢中，如果所查詢的 DNS 服務器與查詢名稱不匹配，則其將返回對較低級別域名空間具有權威性的 DNS 服務器的引用。然后，DNS 客戶端將對引用地址進行查詢。此過程繼續使用查詢鏈中的其他 DNS 服務器，直至發生錯誤或超時為止。
3、非遞歸查詢：當 DNS 解析器客戶端查詢 DNS 服務器以獲取其有權訪問的記錄時通常會進行此查詢，因為其對該記錄具有權威性，或者該記錄存在于其緩存內。DNS 服務器通常會緩存 DNS 記錄，查詢到來后能夠直接返回緩存結果，以防止更多帶寬消耗和上游服務器上的負載。
DNS緩存
DNS 緩存(DNS caching) 有時也叫做 DNS 解析器緩存，它是由操作系統維護的臨時數據庫，它包含有最近的網站和其他 Internet 域的訪問記錄。也就是說， DNS 緩存只是計算機為了滿足快速的響應速度而把已加載過的資源緩存起來，再次訪問時可以直接快速引用的一項技術和手段。那么 DNS 的緩存是如何工作的呢？
DNS緩存的工作流程
在瀏覽器向外部發出請求之前，計算機會攔截每個請求并在 DNS 緩存數據庫中查找域名，該數據庫包含有最近的域名列表，以及 DNS 首次發出請求時 DNS 為它們計算的地址。
DNS緩存方式
DNS 數據可緩存到各種不同的位置上，每個位置均將存儲 DNS 記錄，它的生存時間由 TTL(DNS 字段) 來決定。
瀏覽器緩存
如今的 Web 瀏覽器設計默認將 DNS 記錄緩存一段時間。因為越靠近 Web 瀏覽器進行 DNS 緩存，為檢查緩存并向 IP 地址發出請求的次數就越少。發出對 DNS 記錄的請求時，瀏覽器緩存是針對所請求的記錄而檢查的第一個位置。
在 chrome 瀏覽器中，你可以使用 chrome://net-internals/#dns 查看 DNS 緩存的狀態；
操作系統內核緩存
在瀏覽器緩存查詢后，會進行操作系統級 DNS 解析器的查詢，操作系統級 DNS 解析器是 DNS 查詢離開你的計算機前的第二站，也是本地查詢的最后一個步驟。
DNS報文
共同實現 DNS 分布式數據庫的所有 DNS 服務器存儲了資源記錄(Resource Record, RR)，RR 提供了主機名到 IP 地址的映射。每個 DNS 回答報文中會包含一條或多條資源記錄。RR 記錄用于回復客戶端查詢。
資源記錄包含了以下四個元素：
(Name, Value, Type, TTL)RR 會有不同的類型，下面是不同類型的 RR 匯總表
| A 記錄 | IPv4 主機記錄，用于將域名映射到 IPv4 地址 |
| AAAA 記錄 | IPv6 主機記錄，用于將域名映射到 IPv6 地址 |
| CNAME 記錄 | 別名記錄，用于映射 DNS 域名的別名 |
| MX 記錄 | 郵件交換器，用于將 DNS 域名映射到郵件服務器 |
| PTR 記錄 | 指針，用于反向查找（IP地址到域名解析） |
| SRV 記錄 | SRV記錄，用于映射可用服務。 |
DNS 有兩種報文，一種是查詢報文，一種是響應報文，并且這兩種報文有著相同的格式，下面是 DNS 的報文格式；
上圖顯示了 DNS 的報文格式，其中事務 ID、標志、問題數量、回答資源記錄數、權威名稱服務器計數、附加資源記錄數這六個字段是 DNS 的報文段首部，報文段首部一共有 12 個字節；
報文段首部
報文段首部是 DNS 報文的基礎結構部分，下面我們對報文段首部中的每個字節進行描述
- 事務 ID: 事務 ID 占用 2 個字節。它是 DNS 的標識，又叫做 標識符，對于請求報文和響應報文來說，這個字段的值是一樣的，通過標識符可以區分 DNS 應答報文是對哪個請求進行響應的。
- 標志：標志字段占用 2 個字節。標志字段有很多，而且也比較重要，下面列出來了所有的標志字段；
每個字段的含義如下
-
QR(Response): 1 bit 的 QR 標識報文是查詢報文還是響應報文，查詢報文時 QR = 0，響應報文時 QR = 1。
-
OpCode: 4 bit 的 OpCode 表示操作碼，其中，0 表示標準查詢，1 表示反向查詢，2 表示服務器狀態請求。
-
AA(Authoritative): 1 bit 的 AA 代表授權應答，這個 AA 只在響應報文中有效，值為 1 時，表示名稱服務器是權威服務器；值為 0 時，表示不是權威服務器。
-
TC(Truncated): 截斷標志位，值為 1 時，表示響應已超過 512 字節并且已經被截斷，只返回前 512 個字節。
-
RD(Recursion Desired): 這個字段是期望遞歸字段，該字段在查詢中設置，并在響應中返回。該標志告訴名稱服務器必須處理這個查詢，這種方式被稱為一個遞歸查詢。如果該位為 0，且被請求的名稱服務器沒有一個授權回答，它將返回一個能解答該查詢的其他名稱服務器列表。這種方式被稱為迭代查詢。
-
RA(Recursion Available): 可用遞歸字段，這個字段只出現在響應報文中。當值為 1 時，表示服務器支持遞歸查詢。
-
zero: 保留字段，在所有的請求和應答報文中，它的值必須為 0。
-
AD: 這個字段表示信息是否是已授權。
-
CD: 這個字段表示是否禁用安全檢查。
-
rcode（Reply code）：這個字段是返回碼字段，表示響應的差錯狀態。當值為 0 時，表示沒有錯誤；當值為 1 時，表示報文格式錯誤（Format error），服務器不能理解請求的報文；當值為 2 時，表示域名服務器失敗（Server failure），因為服務器的原因導致沒辦法處理這個請求；當值為 3 時，表示名字錯誤（Name Error），只有對授權域名解析服務器有意義，指出解析的域名不存在；當值為 4 時，表示查詢類型不支持（Not Implemented），即域名服務器不支持查詢類型；當值為 5 時，表示拒絕（Refused），一般是服務器由于設置的策略拒絕給出應答，如服務器不希望對某些請求者給出應答。
問題區域
問題區域通常指報文格式中查詢問題的區域部分。這部分用來顯示 DNS 查詢請求的問題，包括查詢類型和查詢類；
這部分中每個字段的含義如下
- 查詢名：指定要查詢的域名，有時候也是 IP 地址，用于反向查詢。
- 查詢類型：DNS 查詢請求的資源類型，通常查詢類型為 A 類型，表示由域名獲取對應的 IP 地址。
- 查詢類：地址類型，通常為互聯網地址，值為 1 。
資源記錄部分
資源記錄部分是 DNS 報文的最后三個字段，包括回答問題區域、權威名稱服務器記錄、附加信息區域，這三個字段均采用一種稱為資源記錄的格式，如下圖所示：
資源記錄部分的字段含義如下
- 域名：DNS 請求的域名。
- 類型：資源記錄的類型，與問題部分中的查詢類型值是一樣的。
- 類：地址類型、與問題中的查詢類值一樣的。
- 生存時間：以秒為單位，表示資源記錄的生命周期。
- 資源數據長度：資源數據的長度。
- 資源數據：表示按查詢段要求返回的相關資源記錄的數據。
DNS安全
幾乎所有的網絡請求都會經過 DNS 查詢，而且 DNS 和許多其他的 Internet 協議一樣，系統設計時并未考慮到安全性，并且存在一些設計限制，這為 DNS 攻擊創造了機會。
- 第一種是 Dos 攻擊，這種攻擊的主要形式是使重要的 DNS 服務器比如 TLD 服務器或者根域名服務器過載，從而無法響應權威服務器的請求，使 DNS 查詢不起作用。
- 第二種攻擊形式是 DNS 欺騙，通過改變 DNS 資源內容，比如偽裝一個官方的 DNS 服務器，回復假的資源記錄，從而導致主機在嘗試與另一臺機器連接時，連接至錯誤的 IP 地址。
- 第三種攻擊形式是 DNS 隧道，這種攻擊使用其他網絡協議通過 DNS 查詢和響應建立隧道。攻擊者可以使用 SSH、TCP 或者 HTTP 將惡意軟件或者被盜信息傳遞到 DNS 查詢中，這種方式使防火墻無法檢測到，從而形成 DNS 攻擊。
- 第四種攻擊形式是 DNS 劫持，在 DNS 劫持中，攻擊者將查詢重定向到其他域名服務器。這可以通過惡意軟件或未經授權的 DNS 服務器修改來完成。盡管結果類似于 DNS 欺騙，但這是完全不同的攻擊，因為它的目標是名稱服務器上網站的 DNS 記錄，而不是解析程序的緩存。
- 第五種攻擊形式是 DDoS 攻擊，也叫做分布式拒絕服務帶寬洪泛攻擊，這種攻擊形式相當于是 Dos 攻擊的升級版
DNS防火墻
有一些攻擊是針對服務器進行的，這就需要 DNS 防火墻的登場了，DNS 防火墻是一種可以為 DNS 服務器提供許多安全和性能服務的工具。DNS 防火墻位于用戶的 DNS 解析器和他們嘗試訪問的網站或服務的權威名稱服務器之間。防火墻提供 限速訪問，以關閉試圖淹沒服務器的攻擊者。如果服務器確實由于攻擊或任何其他原因而導致停機，則 DNS 防火墻可以通過提供來自緩存的 DNS 響應來使操作員的站點或服務正常運行。
除了上述兩種防御手段外，本身 DNS 區域的運營商就會采取進步一措施保護 DNS 服務器，比如配置 DNS 基礎架構，來防止 DDoS 攻擊。
參考文獻
負載均衡（SLB）使用最佳實踐
DNS
總結
以上是生活随笔為你收集整理的SLB负载均衡和DNS协议的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 理性情绪
- 下一篇： 开发微领地小蜜系统APP平台