跳到主要內容
黯羽輕揚每天積累一點點

DNS_系統設計筆記 3

免費2020-01-19#Back-End#DNS zone#DNS区域#DNS SOA record#DNS实现原理#DNS架构

從技術角度來講，DNS 是個層次型分佈式數據庫，加上一些既定協議

一.DNS 是什麼？

DNS（Domain Name System）相當於互聯網的通訊錄，能夠把域名（www.example.com）翻譯成 IP 地址（93.184.216.34）：

Address book for all of internet.

從技術角度來講，DNS 是個層次型分佈式數據庫，加上一些既定協議，包括數據庫的查詢和更新機制、不同服務器間數據庫信息的複製機制，以及數據庫模式（Schema）。

DNS architecture is a hierarchical distributed database and an associated set of protocols.

P.S.除層次型數據庫外，還有關係型數據庫和網狀數據庫。

二.DNS 的由來

DNS 源於互聯網的早期，當時的互聯網還是美國國防部（the United States Department of Defense）出於研究目的而建立的小型網絡。通過一個 HOSTS 文件來管理網絡中各個計算機的主機名，而這份 HOSTS 文件放在一台集中管理的服務器上，需要解析主機名的每個站點都要先下載這份文件。

隨著網絡中主機數量的不斷增加，HOSTS 文件更新過程所產生的流量以及文件大小問題逐漸暴露出來。於是，期望建立一個能夠靈活擴展，支持各種數據類型的分佈式主機名管理系統，作為互聯網中關鍵的基礎設施。

而這個新的分佈式系統就是DNS（Domain Name System）。

P.S.最早的 DNS 規範是 RFC 882 和 RFC 883，後來被 RFC 1034 和 RFC 1035 所取代，之後的相關規範在此基礎上擴展了安全、實施、管理等部分。

三.基本概念

域名

FQDN

其中，各部分都有對應的名稱：

  • 根域（Root domain）：樹根，表示未命名的一級，例如 www.example.com. 末尾的點號

  • 頂級域（Top-level domain）：用來表示國家、區域或者組織類型，例如.com、.edu

  • 二級域（Second-level domain）：長度不固定，由個人或組織註冊，例如example.com.中的example 部分

  • 子域（Subdomain）：從二級域派生而來，由持有二級域的組織/個人自行創建，例如 www.example.com

  • 主機名/資源名（Host or resource name）：樹結構中的葉子，例如 api.aws.amazon.com 中最左邊的 api

P.S.另外，圖中的 FQND 是指完整域名（Fully Qualified Domain Name），由主機名和域名構成，能夠唯一標識主機在樹結構中的位置。

頂級域由管理 DNS 的域名註冊機構負責維護，按國家或區域分配給各個組織，例如：

  • .com：商業組織（Commercial organizations）

  • .edu：教育機構（Educational institutions）

  • .org：非盈利組織（Non-profit organizations）

  • .net：網絡服務商（Networks (the backbone of the Internet)）

  • .gov：非軍方政府組織（Non-military government organizations）

  • mil：軍方政府組織（Military government organizations）

  • arpa：反向 DNS（Reverse DNS）

  • .**：兩個字母的國家代碼，如.us、.au、.ca、.fr

以 mydomain.microsoft.com.（末尾點號.表示���域）為例：

資源記錄

資源記錄（resource record，簡稱 RR）組成了 DNS 數據庫，常見的有以下幾種：

  • A 記錄（Address record）：地址記錄，把域名指向 IP 地址

  • AAAA 記錄（IPv6 address record）：IPv6 地址記錄，相當於支持 IPv6 的 A 記錄

  • CAA 記錄（Certification Authority Authorization）：證書頒發機構授權記錄，用來指定允許哪些 CA 機構為域名頒發證書

  • CNAME 記錄（Canonical name record）：別名記錄，把一個域名指向另一個域名，或其它 CNAME 記錄、A 記錄

  • MX 記錄（Mail exchange record）：郵件交換記錄，指定用來接收消息的郵件服務器，如有多個郵件服務器，可指定各自的優先級

  • NAPTR 記錄（Naming Authority Pointer）：允許通過正則表達式匹配並替換域名，比如網絡電話系統把用戶輸入的電話號碼轉換成 SIP URI

  • NS 記錄（Name server record）：域名服務器記錄，指定解析域名和子域名所使用的 DNS 服務器

  • PTR 記錄（PTR Resource Record）：PTR 記錄，把 IP 地址指向域名，與 CNAME 的區別在於直接結束並返回結果，多用於反向解析（通過 IP 反查域名）

  • SOA 記錄（Start of authority record）：指定 DNS 權威信息，包括主域名服務器，域名管理員的郵箱，域名序列號等等

  • SPF 記錄（Sender Policy Framework record）：發件人策略框架記錄，早期用於驗證郵件發件人的身份，已廢棄，建議使用 TXT 記錄代替

  • SRV 記錄（Service locator record）：通用服務定位記錄，指定服務所在的服務器（域名和端口號），多用於 SIP（Session Initiation Protocol，會話發起協議）

  • TXT 記錄（Text record）：文本記錄，用於字符串

其中，CAA 記錄是一種證書安全機制，CA 機構頒發證書時會檢查 CAA 記錄，若未授權就拒絕為該域名頒發證書，具體見 DNS Certification Authority Authorization。

注意，NS 記錄與 SOA 記錄不太容易理解，與 DNS 的結構有關，具體見下文結構部分。

P.S.其餘近百種 DNS 記錄類型，見 List of DNS record types。

例如：

# A 記錄
$ dig -t A ayqy.net
ayqy.net.		600	IN	A	121.42.135.10

# CNAME 記錄
$ dig -t CNAME www.baidu.com
www.baidu.com.		600	IN	CNAME	www.a.shifen.com.

# NS 記錄
$ dig -t NS ayqy.net
ayqy.net.		86400	IN	NS	dns10.hichina.com.
ayqy.net.		86400	IN	NS	dns9.hichina.com.

# MX 記錄
$ dig -t MX ayqy.net
ayqy.net.		600	IN	MX	10 mxw.mxhichina.com.
ayqy.net.		600	IN	MX	5 mxn.mxhichina.com.

P.S.其中第二列是上面提到的緩存相關的 TTL（Time-to-Live）值，單位是秒。

路由策略

除基本的映射規則外，DNS 服務可能還支持一些路由策略，比如：

  • 基於權重的路由策略（Weighted routing policy）：根據指定的權重值按優先級分發流量，可用於 A/B 測試、藍綠部署 等場景

  • 基於延遲的路由策略（Latency routing policy）：根據延遲情況解析域名，比如選擇延遲最小的 IP

  • 基於地理位置的路由策略（Geolocation routing policy）：根據用戶的地理位置（各國、各大洲等）解析域名

  • 基於地理位置鄰近程度的路由策略（Geoproximity routing policy）：根據用戶所在地與目標資源所在地的臨近程度解析域名

  • 故障轉移路由策略（Failover routing policy）：用於 主動 - 被動故障轉移模式，一個 IP 出問題之後換用另一個 IP

  • 多值應答路由策略（Multivalue answer routing policy）：簡單的 DNS 層 負載均衡，可配置一對多映射，從中隨機選取

P.S.關於路由策略的更多信息，見 創建和管理流量策略。

四.結構

DNS 域空間被劃分成區域（Zone）進行管理，區域相當於 DNS 服務器的管轄範圍。

區域

一個 DNS 數據庫會被劃分成多個區域，每個區域包含域空間中連續的部分的資源記錄及其 owner 信息，所形成的*區域文件（Zone files）*由 DNS 服務器負責維護，而一個 DNS 服務器能夠管理零到多個區域。

每個區域對應特定的域名，叫做該區域的根域名（Root domain），區域中包含所有以區域根域名結尾的域名信息。區域文件中的第一條記錄是 SOA（Start of Authority）資源記錄，標識出該區域中作為最佳信息源的主 DNS 域名服務器，以及信息更新相關的一些定時器（如 Refresh Interval、Expire Time 等等）。

委託

區域中的域名可以委託給另一個位於不同 DNS 服務器上的區域，*委託（Delegation）*就是把 DNS 空間的一部分交由另一個 DNS 服務器負責的過程，比如另一個組織、部門或工作組。這種委託關係通過 NS 資源記錄來標識，記錄中指定了被委託的區域和與之對應的權威服務器域名。

跨區域委託是 DNS 最初的設計目標之一，為了滿足：

  • 把一個 DNS 域的管理工作委託給多個組織或部門

  • 把一個大 DNS 數據庫的維護工作分散到多個 DNS 服務器上，以提升域名解析性能，和容錯性

  • 根據組織隸屬關係，把主機放到合適的域下

需要跨區域解析域名時，就詢問 NS 記錄中的目標區域的 DNS 服務器。

例如，microsoft.com.被委託給microsoft.com和mydomain.microsoft.com兩個區域管理：

五.實現原理

複製機制

域空間中的同一部分可以由多個區域來表示，分為：

  • 主區域（Primary）

  • 輔助區域（Secondary）

  • 存根區域（Stub）

區域下所有記錄的更新都發生在主區域，輔助區域和存根區域都是只讀的主區域副本，區別在於存根區域只含用來標識權威服務器（託管這三種區域的 DNS 服務器）的記錄。而託管主區域的 DNS 服務器就是該區域的主 DNS 服務器，託管輔助區域的 DNS 服務器是輔助 DNS 服務器。

主 DNS 服務器（或輔助 DNS 服務器）上的區域文件可以被複製到多個 DNS 服務器，這個過程叫區域傳輸（Zone transfer），傳輸方式分為 2 種：

  • 推：主 DNS 服務器在區域文件發生變化時，通知一個或多個輔助 DNS 服務器

  • 拉：輔助 DNS 服務器上的 DNS 服務啟動時，以及區域文件的刷新間隔過期時，輔助服務器就主動向主 DNS 服務器詢問變化

根據所傳輸的數據量分為：

  • 全量：AXFR（A Full Zone Transfer），傳輸所有記錄

  • 增量：IXFR（incremental zone transfer），只傳輸有改動的記錄

查詢機制

DNS 查詢發生在 DNS 客戶端與 DNS 服務器，以及兩個 DNS 服務器之間，一般會一次性查詢特定域名的一組記錄，比如其所有 A 記錄。

具體的，DNS 查詢分為 2 種：

  • 遞歸查詢（Recursive）：DNS 服務器必須聯繫相關的其它 DNS 服務器

  • 迭代查詢（Iterative）：DNS 服務器根據本地數據作出響應，如果實在無法解析，就返回一個否定響應

前者常用於 DNS 客戶端（如 DNS 解析器）和 DNS 轉發服務，如果僅靠本地數據（本地區域文件以及之前查詢的結果緩存）無法解析，就上升到根 DNS 服務器（轉發服務先上升到源服務器）。後者常用於 DNS 服務查詢其域之外的域名，此時可能要詢問多個外部 DNS 服務器才能完成解析。

以 www.whitehouse.gov 為例：

具體查詢過程如下：

  1. 客戶端向本地 DNS 服務器發起遞歸查詢（A 記錄）

  2. 本地 DNS 服務器向根 DNS 服務器發起迭代查詢（A 記錄）

  3. 根 DNS 服務器返回.gov域名服務器的引用（A 記錄）

  4. 本地 DNS 服務器向.gov域名服務器發起迭代查詢（A 記錄）

  5. .gov域名服務器返回whitehouse.gov域名服務器的引用（NS 記錄）

  6. 本地 DNS 服務器向 whitehouse.gov 域名服務器發起迭代查詢（A 記錄）

  7. whitehouse.gov 域名服務器回應迭代查詢（www.whitehouse.gov 的 IP 地址）

  8. 本地 DNS 服務器回應最初的遞歸查詢（www.whitehouse.gov 的 IP 地址）

P.S.其中，引用（DNS Referral）是指間接答案：

DNS Referrals. The term referral indicates a response to a query which does not contain an answer section (it is empty) but which contains one or more authoritative name servers (in the Domain Authority section) that are closer to the required query question.

具體見 DNS Referrals。

緩存機制

資源記錄中的 TTL（Time-to-Live）值相當於該記錄的保質期，其它 DNS 服務器根據 TTL 來決定該把這條信息緩存多久。如果記錄沒有指定自身的 TTL 的話，DNS 服務器會從 SOA 記錄繼承默認 TTL，以防其它 DNS 服務器對資源記錄進行擴展緩存。

客戶端的 DNS 解析器也會緩存所收到的 DNS 查詢結果，緩存時長同樣遵循 TTL。DNS 服務器用查詢緩存應答時，會把緩存的 TTL 傳遞下去，接收方以收到的 TTL 值為準（而不根據自己的 TTL 重置），以保證資源記錄能夠正常過期。

設置 TTL 需要考慮緩存信息的準確性，以及 DNS 服務器的效用和網絡流量問題，二者有些衝突。如果 TTL 太短，出現舊信息的可能性雖然降低了，但 DNS 服務器的效用問題和流量問題就冒出來了，而 TTL 太長的話，緩存信息可能會過時，意味著解析器可能會返回錯誤的結果，但能夠減輕效用問題和流量問題。

P.S.關於 DNS 緩存及更新的更多信息，見 DNS Processes and Interactions。

至此，DNS 的裡裡外外就都清楚了。

參考資料

評論

暫無評論，快來發表你的看法吧

提交評論