什麼是 DNS？ 域名系統簡介

當您坐在電腦前時，互聯網似乎很簡單。 您打開瀏覽器，輸入域名，然後在屏幕上查看網站。 然而，在圖形用戶界面 (GUI) 下方是一個由軟件和服務器組成的擴展網絡，稱為域名系統 (DNS)。 但是，什麼是 DNS，它如何幫助我們在設備上查看網絡？

這個問題的答案很複雜，因為涉及到大量的運動部件。 您會發現鏈中的幾乎每個環節都使用服務器。 更重要的是，有一些技術可以幫助您減少可能影響快速頁面加載速度的瓶頸。

在這篇文章中，我們將以最直接的方式幫助您了解 DNS。 讓我們總結一下本文將要介紹的內容。

互聯網如何從服務器獲取網頁到您的瀏覽器

總而言之，DNS 是我們將可讀域名轉換為它所代表的最終 Internet 協議 (IP) 地址的方式。 雖然這表面上看起來是一項簡單的任務，但事實遠非如此。

每個網站都存在於服務器上，每個服務器（實際上是計算機）都有一個 IP 地址。 DNS是將IP地址映射到域名的系統，因此我們可以享受用戶友好的瀏覽。 作為一個類比，想想街道名稱和房屋地址實際上是一組地圖坐標。 我們使用街道地址來簡化位置的經度和緯度。

當您將 IP 地址轉換為域名時（反之亦然），這就是“DNS 解析”。 該鏈中有許多硬件組件，特別是四種不同類型的服務器。 讓我們接下來討論這些。

獲取和加載網頁的 4 個 DNS 服務器

每個 DNS 請求和解析都經過四台服務器。 簡而言之，它們是：

• DNS 遞歸器。 這是整個 DNS 的“水載體”。 當您從瀏覽器請求網站時，您會告訴遞歸器在 DNS 中查找（或“查找”）該站點。
• 根名稱服務器。 如果您考慮一個包含大量站點的 Web 服務器，那麼根名稱服務器就代表了整體。 它是 IP 地址的一般位置。
• 頂級域 (TLD) 名稱服務器。 網站將存在於根名稱服務器中，但 TLD 名稱服務器將挖掘出 IP 地址的最後部分：主機名的結尾部分。 這可能是 .com、.net 或無數其他。
• 權威的域名服務器。 為了使這個複雜的服務器變得簡單，它是 IP 地址的參考庫。 該服務器會將完整的 IP 地址發送回遞歸器，然後遞歸器會在您的瀏覽器中顯示該站點。

在查詢解析之前，DNS 查詢會經歷所有這些步驟，甚至多次。 因此，鏈中有很多點會導致查詢失敗——這就是為什麼我們會出現 HTTP 錯誤。

不過，值得更詳細地深入研究這條鏈的正面和背面。 接下來讓我們這樣做。

DNS Recursor 和 Authoritative Nameserver 的區別

您將了解遞歸器獲取查詢的結果，並且是整個 DNS 過程的開始。 反過來，您還將知道權威名稱服務器將此過程的結果傳遞回遞歸器。 但是，兩者都有更多您需要了解的差異：

• DNS 遞歸器。 此服務器響應 DNS 查詢請求。 它之所以活躍，是因為它沿著鏈跟踪 DNS 記錄。 雖然遞歸器的典型方法是向其他服務器發出多個請求，但緩存可以減少這段時間。 稍後我們將詳細討論這一點。
• 權威名稱服務器。 此服務器保存所有 DNS 記錄。 它的工作是根據從鏈中其他服務器（包括遞歸器）接收到的信息來響應請求。 正是這個服務器讓瀏覽器顯示一個網站。 因為它是權威的，所以它不需要諮詢其他來源來驗證查詢——它是事實的來源。

但是，雖然權威名稱服務器是 DNS 請求的端點，但並不總是這樣。 在此之後，您還將根據請求找到其他名稱服務器。

如果 DNS 查詢是針對子域（例如 shop.example.com），您會發現在權威域名服務器之後會有一個額外的域名服務器。 這將存儲相關子域的CNAME記錄。

理論上，查詢請求的額外名稱服務器的數量沒有限制。 但是，大多數時候，只會有一個額外的名稱服務器。

DNS 查找的工作原理

雖然有四台服務器處理 DNS 查找和查詢，但鏈中有很多步驟傳遞查詢並獲取結果。 以下是查找過程的工作原理：

• 您將在瀏覽器中輸入域名。 單擊Enter後，查詢將從您的瀏覽器和操作系統 (OS) 進入 DNS 遞歸器接收它的 Internet。
• 遞歸器將此查詢傳遞給根名稱服務器，並執行自己的查詢。
• 此查詢的結果將是 TLD 名稱服務器，它返回給遞歸器。
• 這一次，遞歸器查詢 TLD 名稱服務器，它以域的權威名稱服務器的 IP 地址進行響應。
• 遞歸器向權威名稱服務器發送另一個查詢，後者又以初始域請求的 IP 地址進行響應。

從這裡，遞歸器將其工作結果發送回 Web 瀏覽器。 這樣就完成了 DNS 過程，遞歸器可以休息幾毫秒！ 然後瀏覽器將處理 HTTP 請求，以便在瀏覽器中顯示該站點。

有許多複雜且勞動密集型的步驟（相對於服務器可以實現的目標），這種情況在全世界每秒發生數十億次。 即便如此，在一次查找中也只會發生三個查詢。

您將在 DNS 查找中找到的查詢

DNS 客戶端和服務器之間的每個查詢都存在關係。 雖然這些是通用術語，但我們會在解釋中註明任何細節：

• 遞歸查詢。 在此查詢中，客戶端將請求 DNS 遞歸器以請求的 DNS 記錄或錯誤消息進行響應。
• 迭代查詢。 此查詢為遞歸器提供免費許可，以對其返回的內容進行“最佳猜測”。 如果查詢不匹配，則結果將被引薦到較低級別的權威服務器，直到此“路徑”耗盡。
• 非遞歸查詢。 如果緩存中存在 DNS 記錄，或者遞歸器對記錄具有權威訪問權限，您會發現此查詢將發生。 我們將在本文末尾討論緩存。

在很多情況下，您會發現遞歸和非遞歸查詢是最常見的。 這就是您會看到錯誤消息以及查找過程可能很複雜的原因。

DNS緩存入門

當您處理非遞歸查詢時，記錄有機會駐留在 DNS 記錄的專用緩存中。 如果您了解緩存，您就會明白它會包含您定期訪問的文件。 本地應用程序可以做到這一點，但您網站的緩存是最好的例子：

這將保存您站點文件的記錄，以便您可以減少 HTTP 請求的數量。 DNS 記錄也是如此。 這使相關記錄更靠近您的計算機位置，以便您可以比通常更快的速度獲取 IP 地址。

對於 Web 開發人員， GET請求是瀏覽器發出的。 使用緩存，遞歸器切斷鍊中的其他服務器，或者直接進入權威名稱服務器，或者在不需要進一步查詢的情況下調用它。 這是您可以進行的最典型的非遞歸查詢。

事實上，您會發現跨多種技術的 DNS 緩存，例如您的 Internet 服務提供商 (ISP)、路由器和本地計算機。

您會發現您的瀏覽器緩存是尋找 DNS 記錄的遞歸器的第一個調用端口，因此，瀏覽器通常會將記錄緩存為默認設置。 您的操作系統還將有一個 DNS 解析器，它還會檢查其緩存中的 DNS 記錄。

同樣，如果操作系統在其緩存中不包含該記錄，它會將查詢發送到您的 ISP 遞歸器進行處理。 這兩個遞歸器都將與您的域的A和NS記錄一起使用，以在完整的查找過程發生之前嘗試解決查詢。

更改 DNS 記錄：“傳播”

說到這一點，您可以通過您的註冊商對您的A 、 NS或CNAME記錄進行更改。 在很多情況下，在所有這些更改註冊之前，總共需要 72 小時。

這是 DNS 傳播，完成所需的時間取決於許多因素 - 即相關記錄的生存時間 (TTL) 值：

簡而言之，這決定了更改對特定 DNS 記錄生效的速度。 典型的 TTL 約為 4 小時，值越高，傳播所需的時間越長。

註冊商通常會為您的域名服務器設置 TTL，因此，您或其他任何人都無法進行更改。 這就是為什麼您經常必須等待傳播完成，以及為什麼您會不斷檢查諸如我的 DNS 是什麼之類的站點的原因。 衡量其進展：

解決方案是在決定更改 DNS 記錄之前盡可能多地設置 TTL。 當然，註冊商將負責您的域名服務器，但您會盡可能地減少傳播時間。

結論

如果您認為訪問網頁很簡單，請再想一想。 對於最終用戶來說，這個過程的核心很簡單。 然而，在底層它要復雜得多，並且涉及大量額外的服務器。

這篇文章研究了 DNS——互聯網獲取域名並將其解析為 IP 地址的方式。 從那裡，它可以返回瀏覽器並呈現為網頁。 但是，您會發現許多其他過程也會發生，例如傳播和緩存。 結合起來，它們為我們提供了快速且（大部分）無故障的瀏覽。

您認為本文回答了“什麼是 DNS？”這個問題嗎？如果沒有，您還有其他問題嗎？ 如果是這樣，請在下面的評論部分詢問！