介紹
DNS,即域名系統,通常是學習如何配置網站和伺服器時最困難的部分之一。了解DNS的工作原理將有助於您診斷配置訪問您的網站的問題,並且將允許您擴展對幕後發生情況的理解。
在本指南中,我們將討論一些基本的DNS概念,這將幫助您快速掌握DNS配置。閱讀完本指南後,您應該準備好使用DigitalOcean設置您的域名或設置您自己的DNS伺服器。
在我們開始設置自己的伺服器以解析您的域名或在控制面板中設置我們的域名之前,讓我們先來了解一些有關所有這些實際工作方式的基本概念。
域名術語
我們應該從定義術語開始。雖然這些主題中的一些來自其他上下文的熟悉,但在談論域名和DNS時使用的許多術語在其他計算領域並不常見。
讓我們從簡單的開始:
域名系統
域名系統,更常被稱為“DNS”,是一種網絡系統,它使我們能夠將人類友好的名稱解析為唯一的IP地址。
域名
A domain name is the human-friendly name that we are used to associating with an internet resource. For instance, “google.com
” is a domain name. Some people will say that the “google” portion is the domain, but we can generally refer to the combined form as the domain name.
URL“google.com
”與Google Inc.擁有的伺服器相關聯。 域名系統允許我們在瀏覽器中輸入“google.com
”時訪問Google伺服器。
IP地址
IP地址是我們稱之為網絡可訪問位置的東西。 每個IP地址在其網絡內必須是唯一的。 當我們談論網站時,這個網絡是整個互聯網。
IPv4是最常見的地址形式,以四組數字寫成,每組最多有三個數字,每組之間用點分隔。 例如,“111.222.111.222
”可以是一個有效的IPv4 IP地址。 有了DNS,我們將一個名稱映射到該地址,這樣您就不必為您在網絡上訪問的每個地方記住一組複雜的數字。
頂級域名
A top-level domain, or TLD, is the most general part of the domain. The top-level domain is the furthest portion to the right (as separated by a dot). Common top-level domains are “com”, “net”, “org”, “gov”, “edu”, and “io”.
頂級域名位於域名層級的頂部。ICANN(互聯網名稱與數字地址分配機構)授予某些方管理頂級域名的控制權。然後,這些方可以通過域名註冊機構分配頂級域名下的域名。
主機
在一個域名中,域名所有者可以定義單獨的主機,這些主機是指通過域名訪問的獨立計算機或服務。例如,大多數域名所有者使其 Web 服務器通過裸域名(example.com
)以及通過“主機”定義的“www”(www.example.com
)可訪問。
您可以在一般域名下擁有其他主機定義。您可以通過“api”主機(api.example.com
)訪問 API,也可以通過定義一個名為“ftp”或“files”的主機來訪問 ftp(ftp.example.com
或 files.example.com
)。主機名稱可以是任意的,只要它們對於該域名是唯一的。
子域名
A subject related to hosts are subdomains.
DNS 在層次結構中運作。頂級域名(TLD)可以有許多域名位於其下。例如,“com” TLD 既有“google.com
” 又有“ubuntu.com
”。“子域名” 指的是任何屬於較大域名的一部分的域名。在這種情況下,“ubuntu.com
” 可以說是“com”的子域名。通常只稱為域名或“ubuntu” 部分稱為 SLD,即二級域名。
同樣地,每個域名可以控制位於其下的“子域名”。這通常是我們所指的子域名。例如,您可以在“www.history.school.edu
” 建立學校歷史系的子域名。“history” 部分是一個子域名。
主機名稱和子域名之間的區別在於主機定義了一台計算機或資源,而子域名擴展了父域名。這是對域名本身進行細分的方法。
無論是談論子域名還是主機,您可以開始看到域名的最左邊部分是最具體的。這就是 DNS 的工作方式:從最具體到最不具體,從左到右逐步閱讀。
完全合格的域名
A fully qualified domain name, often called FQDN, is what we call an absolute domain name. Domains in the DNS system can be given relative to one another, and as such, can be somewhat ambiguous. A FQDN is an absolute name that specifies its location in relation to the absolute root of the domain name system.
這意味著它指定了每個父域,包括頂級域名。正確的完全限定域名以點結尾,表示 DNS 階層的根。完全限定域名的示例是“mail.google.com。
”。有時候,需要完全限定域名的軟件並不需要結尾的點,但是為了符合 ICANN 標準,尾隨的點是必需的。
名稱伺服器
A name server is a computer designated to translate domain names into IP addresses. These servers do most of the work in the DNS system. Since the total number of domain translations is too much for any one server, each server may redirect request to other name servers or delegate responsibility for a subset of subdomains they are responsible for.
名稱伺服器可以是“權威的”,這意味著它們對其控制範圍內的域名的查詢給予答案。否則,它們可能指向其他伺服器,或者提供其他名稱伺服器數據的快取副本。
區域文件
A zone file is a simple text file that contains the mappings between domain names and IP addresses. This is how the DNS system finally finds out which IP address should be contacted when a user requests a certain domain name.
區域文件存放在名稱伺服器中,通常定義了特定域名下可用的資源,或者可以獲取該資訊的地方。
記錄
在區域文件中保存記錄。在其最簡單的形式中,記錄基本上是資源和名稱之間的單個映射。這些可以將域名映射到 IP 地址,定義域的名稱伺服器,定義域的郵件伺服器等。
DNS 的運作方式
現在你已經熟悉了一些與 DNS 相關的術語,這個系統到底是如何運作的呢?
在高層次上,這個系統非常簡單,但在細節上非常複雜。總的來說,它是一個非常可靠的基礎設施,對於我們今天網際網路的普及至關重要。
根域名服務器
正如我們上面所說的,DNS 在其核心上是一個分層系統。在這個系統的頂部是所謂的“根域名服務器”。這些服務器由各種組織控制,並由 ICANN(互聯網名稱與數字地址分配機構)委派權限。
目前有 13 個根域名服務器在運作。然而,由於每分鐘需要解析的名稱數量非常多,因此每個根域名服務器的每個鏡像實際上都是成對存在的。這個設置的有趣之處在於,單個根域名服務器的每個鏡像共享相同的 IP 地址。當對某個特定根域名服務器發出請求時,該請求將被路由到該根域名服務器的最近的鏡像。
這些根伺服器是做什麼的?根伺服器處理有關頂級域的信息請求。因此,如果一個較低級別的名稱伺服器無法解析某個請求,則會向根伺服器查詢該域的信息。
根伺服器實際上並不知道該域位於何處。然而,它們能夠將請求方引導到處理具體請求的頂級域名伺服器。
因此,如果對“www.wikipedia.org”的請求發送到根伺服器,則根伺服器將無法在其記錄中找到結果。它將檢查其區域文件,尋找與“www.wikipedia.org”匹配的列表,但找不到。
相反,它會在“org”頂級域名的記錄中找到一條記錄,並將負責“org”地址的名稱伺服器的地址提供給請求方。
頂級域名伺服器
然後,請求方向負責該請求的頂級域名的IP地址(由根伺服器提供)發送新的請求。
因此,繼續我們的例子,它將向負責了解“org”域的名稱伺服器發送一個請求,以查詢它是否知道“www.wikipedia.org”的位置。
再次,請求方將在其區域文件中尋找“www.wikipedia.org”的記錄,但找不到。
然而,它將找到一條記錄列出了負責“wikipedia.org
”的名稱伺服器的IP地址。這讓我們離我們想要的答案更近了。
域級別名稱伺服器
在這一點上,請求者已經獲得了負責知道實際IP地址的資源的名稱伺服器的IP地址。它再次向名稱伺服器發送一個新的請求,詢問是否可以解析“www.wikipedia.org
”。
名稱伺服器檢查其區域文件,並發現它與“wikipedia.org
”關聯的區域文件。在這個文件中,有一條關於“www”主機的記錄。這個記錄告訴這個主機所在的IP地址。名稱伺服器將最終答案返回給請求者。
什麼是解析名稱伺服器?
在上述情景中,我們提到了一個“請求者”。在這種情況下,請求者是什麼?
幾乎在所有情況下,請求者將是我們所謂的“解析名稱伺服器”。 解析名稱伺服器被配置為向其他伺服器提問。 它基本上是用戶的中介,會緩存先前的查詢結果以提高速度,並知道根伺服器的地址,以便能夠“解析”對於它尚不了解的事物所做的請求。
基本上,用戶通常會在其計算機系統上配置幾個解析名稱伺服器。 解析名稱伺服器通常由ISP或其他組織提供。 例如,Google提供可查詢的解析DNS伺服器。 這些可以自動或手動配置在您的計算機上。
當您在瀏覽器的地址欄中輸入URL時,您的計算機首先查看本地是否能夠找到資源的位置。 它檢查計算機上的“hosts”文件和一些其他位置。 然後,它將請求發送給解析名稱伺服器,並等待收到資源的IP地址。
然後,解析名稱伺服器檢查其緩存以獲取答案。 如果找不到,則按照上述步驟進行。
解析名稱伺服器基本上壓縮了最終用戶的請求過程。 用戶只需知道向解析名稱伺服器詢問資源位於何處,並確信它們將調查並返回最終答案。
區域檔案
在上述過程中,我們提到了“區域檔案”和“記錄”的概念。
區域檔案是域名伺服器存儲有關其了解的域名信息的方式。每個域名伺服器了解的域名都存儲在一個區域檔案中。對於普通域名伺服器的大多數請求來說,它並不會有相應的區域檔案。
如果配置為處理遞歸查詢,如解析域名伺服器,它將查找答案並返回。否則,它會告訴請求方應該去哪裡查找。
域名伺服器擁有的區域檔案越多,它能夠權威地回答的請求就越多。
A zone file describes a DNS “zone”, which is basically a subset of the entire DNS naming system. It generally is used to configure just a single domain. It can contain a number of records which define where resources are for the domain in question.
該區域的$ORIGIN
是一個默認等於該區域最高權威的參數。
因此,如果一個區域檔案用於配置“example.com.
”域名,則$ORIGIN
將被設置為example.com.
。
這個參數可以配置在區域檔案的頂部,或者可以在引用區域檔案的DNS伺服器配置檔中定義。無論哪種方式,該參數描述了該區域將成為權威的內容。
同樣地,$TTL
配置了提供的信息的“存活時間”。它基本上是一個計時器。緩存域名伺服器可以使用以前查詢的結果來回答問題,直到TTL值用完。
記錄類型
在區域文件中,我們可以有許多不同的記錄類型。我們將在這裡介紹一些比較常見(或必須的類型)。
SOA記錄
權威起始,或SOA記錄,在所有區域文件中都是一個必需的記錄。它必須是文件中的第一個真正的記錄(儘管$ORIGIN
或$TTL
規範可以出現在其上方)。它也是最難理解的之一。
權威起始記錄看起來像這樣:
domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)
讓我們解釋一下每個部分的用途:
-
domain.com.
:這是區域的根。這指定了該區域文件是為了domain.com.
域。通常,您會看到這被替換為@
,這只是一個佔位符,代替了我們上面學到的$ORIGIN
變量的內容。 -
在SOA: “IN”部分表示互联网(并且将出现在许多记录中)。 SOA是指这是一个权威记录的指示符。
-
ns1.domain.com.
:这定义了此域的主要名称服务器。名称服务器可以是主要的或次要的,如果配置了动态DNS,则一个服务器需要是“主要”的,它放在这里。如果您尚未配置动态DNS,则这只是您的一个主要名称服务器。 -
admin.domain.com.
:这是该区域管理员的电子邮件地址。电子邮件地址中的“@”将被点替换。如果电子邮件地址的名称部分通常包含一个点,那么在此部分将其替换为“\”([email protected]
变为your\name.domain.com
)。 -
12083:這是該區域文件的序列號。每次編輯區域文件時,必須增加此號碼,以便區域文件能正確傳播。次級伺服器將檢查主要伺服器對於區域的序列號是否大於其系統中存在的序列號。如果是,它會請求新的區域文件;如果不是,則繼續提供原始文件。
-
3h:這是區域的刷新間隔。這是次級伺服器在輪詢主要伺服器以獲取區域文件更改之前等待的時間。
-
30分鐘:這是該區域的重試間隔。如果次要伺服器在刷新週期結束時無法連接到主要伺服器,它將等待這段時間,然後重試以請求主要伺服器。
-
3週:這是到期期限。如果次要名稱伺服器無法在此時間內與主要伺服器聯繫,則不再將其作為此區域的權威來源返回回應。
-
1小時:這是名稱伺服器在無法在此文件中找到所請求的名稱時將快取名稱錯誤的時間。
A and AAAA Records
這些記錄將主機映射到IP地址。 “A”記錄用於將主機映射到IPv4 IP地址,“AAAA”記錄用於將主機映射到IPv6地址。
這些記錄的一般格式是這樣的:
host IN A IPv4_address
host IN AAAA IPv6_address
所以,由於我們的SOA記錄中指定了一個名為“ns1.domain.com
”的主要伺服器,我們必須將其映射到一個IP地址,因為“ns1.domain.com
”位於此文件定義的“domain.com
”區域內。
記錄可能如下所示:
ns1 IN A 111.222.111.222
請注意,我們不必提供完整的名稱。我們可以只提供主機名,不包括完全合格的域名,DNS伺服器將使用$ORIGIN
值填充其餘部分。但是,如果我們希望語義上更清晰,我們也可以使用完整的完全合格域名:
ns1.domain.com. IN A 111.222.111.222
在大多數情況下,這是您將定義您的Web伺服器為“www”的地方:
www IN A 222.222.222.222
我們還應該告訴基本域名解析到哪裡。我們可以這樣做:
domain.com. IN A 222.222.222.222
我們也可以使用“@
”來引用基本域:
@ IN A 222.222.222.222
我們還可以將未明確定義為此伺服器的域中的任何內容解析為此伺服器。我們可以使用“*
”通配符來實現這一點:
* IN A 222.222.222.222
所有這些對於IPv6地址的AAAA記錄同樣有效。
CNAME記錄
CNAME記錄為您的伺服器定義了一個別名或規範名稱(由A或AAAA記錄定義)。
例如,我們可以有一個A名稱記錄定義“server1”主機,然後使用“www”作為此主機的別名:
server1 IN A 111.111.111.111
www IN CNAME server1
請注意,這些別名會帶來一些性能損失,因為它們需要向服務器發送額外的查詢。大多數情況下,可以通過使用額外的 A 或 AAAA 記錄來實現相同的結果。
建議使用 CNAME 的一種情況是為當前區域之外的資源提供別名。
MX 記錄
MX 記錄用於定義用於該域的郵件交換。這有助於郵件正確到達您的郵件服務器。
與許多其他記錄類型不同,郵件記錄通常不將主機映射到某個東西,因為它們應用於整個區域。因此,它們通常看起來像這樣:
IN MX 10 mail.domain.com.
請注意,開頭沒有主機名。
還請注意其中有一個額外的數字。這是偏好數字,有助於計算機決定如果定義了多個郵件服務器,應將郵件發送到哪個服務器。較小的數字具有較高的優先級。
MX 記錄通常應指向由 A 或 AAAA 記錄定義的主機,而不是由 CNAME 定義的主機。
因此,假設我們有兩個郵件服務器。必須有類似以下的記錄:
IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
在這個例子中,“mail1”主機是首選的電子郵件交換服務器。
我們也可以這樣寫:
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
NS記錄
這種記錄類型定義了用於該區域的名稱服務器。
您可能會問:“如果區域文件位於名稱服務器上,為什麼需要引用自身呢?”DNS成功的一部分是其多級緩存。在區域文件中定義名稱服務器的原因之一是,該區域文件實際上可能是從另一個名稱服務器上的緩存副本提供服務的。需要在名稱服務器自身上定義名稱服務器的其他原因,但我們不會在這裡討論。
與MX記錄一樣,這些是區域範圍的參數,因此它們不接受主機。一般而言,它們看起來像這樣:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
每個區域文件中應至少定義兩個名稱服務器,以便在一台服務器出現問題時能正常運作。大多數DNS服務器軟件認為如果只有一個名稱服務器,則區域文件無效。
一如既往,包含具有A或AAAA記錄的主機的映射:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233
您可以使用許多其他記錄類型,但這些可能是您遇到的最常見的類型。
PTR記錄
PTR记录用于定义与IP地址关联的名称。PTR记录是A或AAAA记录的反向记录。PTR记录的独特之处在于它们从.arpa根开始,并委托给IP地址的所有者。区域性互联网注册机构(RIRs)负责管理IP地址分配给组织和服务提供商。区域性互联网注册机构包括APNIC、ARIN、RIPE NCC、LACNIC和AFRINIC。
以下是一个PTR记录的示例,用于111.222.333.444
:
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
这个IPv6地址的PTR记录示例展示了Google的IPv6 DNS服务器2001:4860:4860::8888
的逆向的nibble格式。
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.
可以使用带有-x
标志的命令行工具dig
来查找IP地址的反向DNS名称。
以下是dig命令的示例。+short
用于缩减输出以显示反向DNS名称。
上述dig命令的输出将是IP地址的PTR记录中的域名:
google-public-dns-b.google.com.
互联网上的服务器使用PTR记录将域名放入日志条目中,做出有根据的垃圾邮件处理决策,并显示有关其他设备的易于阅读的详细信息。
大多數常用的電子郵件伺服器將查找接收到郵件的IP地址的PTR記錄。如果源IP地址沒有與之關聯的PTR記錄,則發送的郵件可能被視為垃圾郵件並被拒收。重要的不是PTR中的完全限定域名(FQDN)是否與發送的郵件的域名匹配,而是有一個有效的PTR記錄,其中包含相應且匹配的前向A記錄。
通常,互聯網上的網絡路由器會根據其物理位置獲得PTR記錄。例如,您可能會看到關於紐約市或芝加哥的路由器的參考。這在運行traceroute或MTR並查看互聯網流量路徑時很有幫助。
大多數提供專用服務器或VPS服務的供應商都會讓客戶設置其IP地址的PTR記錄。當使用特定域名命名Droplet時,DigitalOcean將自動分配任何Droplet的PTR記錄。 Droplet名稱在創建時分配,可以在Droplet控制面板的設置頁面中稍後進行編輯。
注意: PTR記錄中的FQDN應與相應的匹配的前向A記錄相對應。例如:111.222.333.444
具有server.example.com
的PTR,而server.example.com
是指向111.222.333.444
的A記錄。
CAA 記錄
CAA 記錄用於指定哪些證書授權機構(CA)可以為您的域發行 SSL/TLS 證書。截至2017年9月8日,所有 CA 在發行證書之前都必須檢查這些記錄。如果沒有記錄存在,任何 CA 都可以發行證書。否則,只有指定的 CA 可以發行證書。CAA 記錄可以應用於單個主機或整個域。
以下是一個示例 CAA 記錄:
example.com. IN CAA 0 issue "letsencrypt.org"
主機、IN
和記錄類型(CAA
)是常見的 DNS 字段。上述 CAA 特定信息是 0 issue "letsencrypt.org"
部分。它由三部分組成:標誌(0
)、標籤(issue
)和值("letsencrypt.org"
)。
- 標誌是一個整數,指示 CA 應如何處理它不理解的標籤。如果標誌為
0
,則該記錄將被忽略。如果是1
,則 CA 必須拒絕發行證書。 - 標籤是表示 CAA 記錄目的的字符串。目前它們可以是
issue
(授權 CA 為特定主機名創建證書)、issuewild
(授權通配符證書)或iodef
(定義 CA 可以報告策略違規的 URL)。 - 值是與記錄的 標籤 相關的字符串。對於
issue
和issuewild
,這通常是您授予權限的 CA 的域名。對於iodef
,這可能是聯絡表單的 URL,或者是郵件反饋的mailto:
鏈接。
您可以使用 dig
通過以下選項來獲取 CAA 記錄:
有關 CAA 記錄的更詳細信息,您可以閱讀 RFC 6844,或我們的教程 如何使用 DigitalOcean DNS 創建和管理 CAA 記錄
結論
您現在應該對 DNS 的工作原理有了相當不錯的了解。一旦您熟悉了策略,一般的概念相對容易理解,但對於沒有經驗的管理員來說,這仍然可能是一個難以實踐的事情。
總覽請查看 如何在 DigitalOcean 控制面板中設置域名。