關於DNS你應該瞭解的相關概念和原理
什麼是DNS，DNS的全稱是域名系統（Domain Name System）,DNS是在學習配置一個站點或者服務時比較難的一個部分。理解DNS如何工作的原理對你診斷站點訪問配置問題帶來幫助，同時也能加深你對它背後的執行機制的理解。
在這篇文章中，我們將會討論一些關於DNS的基本概念，這些概念會在你配置DNS時更好地幫助到你。當然在學習這篇文章前，如果你手頭已經有一個域名那就更好了。
在我們準備開始配置你的站點的域名解析或者在後臺控制面板配置域名之前，讓我們先學習下關於DNS如何工作的相關概念。
Domain域的概念
我們應該從定義術語開始。在討論關於域名和DNS時，雖然其中一些主題在其他上下文中很熟悉，但是在討論域名和DNS時使用的許多術語在其他計算領域中並不常用。 讓我們開始吧：
Domain Name System 域名系統
域名系統(通常稱為“DNS”)是一種網路系統，它允許我們將對人類友好的名稱解析為惟一的地址。
Domain Name 域名
一個域名是我們用來關聯換一個網際網路資源的一個人性化的名字。舉個例子，比如google.com就是一個域名。當然有些人覺得其中的google就是域名，但是我們通常把google.com這個組合稱為域名。
IP Address IP地址
IP地址就是我們說的網路定位定址。在網路中的每一個IP地址都必須唯一。當我們討論網站時，我們說的這個網路指代的就是我們的因特網。
IPv4是最最常見的網路地址形式，他是由4組數字，每組由三個數字構成，組與組之間用點號分割。比如"111.222.111.222"就是一個有效的IPv4的IP地址。使用DNS，我們可以對映一個名字到我們的地址，這樣我們在想要在網路上訪問的時候，就不需要記憶那串複雜的數字了。
Top-Level Domain 頂級域名
頂級域名又稱TLD是域名中最常見的部分。是網際網路DNS等級之中的最高階的域，它保存於DNS根域的名字空間中。頂級域名是域名的最後一個部分，即是域名最後一點之後的字母，例如在example.com這個域名中，頂級域是.com（或.COM），大小寫視為相同。wiki
頂級域名是指域名中的最高層級。這個部分是由ICANN（網際網路名稱與數字地址分配機構） 進行管理分配的，通過域名註冊商在TLD下分發。
Host 主機
有了域名，你就可以定義獨立的host主機，來通過域名訪問不同的計算機和服務。舉個例子，大多數域名擁有者會讓他們的域名既能通過 (example.com)訪問也能通過host主機定義的"www"（www.example.com）來訪問。
你也可以定義其他host主機名。比如：你可以定義api這個host，通過api.example.com來訪問API或者你也可以定義ftp，或者files的host然後通過(ftp.example.com或者files.example.com)來訪問。對於一個域名它底下的host名稱可以隨意只要保證在該域名下唯一就可以。
SubDomain 子域名
和host主機名相關的一個主題就是子域名。
DNS的有層級的。TLD頂級域名底下可以有很多的域名。比如:"com"這個頂級域名下面會有"google.com"和"ubuntu.com"等域名。子域名是指的一個更大域名底下的那些域名。比如這個例子中的"ubuntu.com"就可以被稱作com的一個子域名。我們把其中的ubuntu成為是一個 SLD 二級域名（Secode level domain）。
也就是時候，每個域名可以控制位於它底下的所有子域名。也就是我們通常說的通過子域名。比如你可以為你學學校的歷史系分配一個子域名 "www.history.school.edu"。其中的history部分就是一個子域名。
host name主機名和subdomin子域名之間的區別是，一個host主機定義了一臺計算機或者一個資源。而subdomain是繼承自父域名。他是一種細分域名本身的方法。
不管是討論子域名還是主機host，你都可以發現在一個域名越靠近左側的部分就越特殊。這就是DNS的工作原理：當你從左往右閱讀的時候，就是從特殊到非特殊的過程。
全限定域名
全限定域名，經常被稱為 FQDN。就是我們所說的絕對域名。域名在DNS域名系統中可以通過相對位置來關聯其他部分。因此也就可能比較模糊。FQDN是一個絕對的名字用來指定他和域名系統的絕對根位置的位置關係。
也就是說指定每個父級域名包括TLD頂級域名。一個正確的FQDN以一個點號結尾，表示DNS層次結構中的根。舉個FQDN中的例子"mail.google.com."。有些軟體在呼叫FQDN時並不需要結尾的點，但是尾部的點號對於一個標準的ICANN形式是必須的。
Name Server 名字伺服器
名字伺服器是一臺設計用來轉換域名到IP地址的計算機。這些伺服器在DNS域名系統中做很多事情。因為這麼多數量的域名轉換工作如果都讓一臺伺服器來幹太多了，因此每臺伺服器把請求重定向到其他名字伺服器或當他們響應時委派響應給他們的子域名。
名字伺服器是有"權威性"的，也就是說他們為他們底下控制的域名提供查詢域名的答案。否則，他們就指向其他伺服器，或者快取其他名字伺服器的資料。
Zone File 區域檔案
一個區域檔案是一個簡單的文字包含了域名名字和IP地址之間的對映。這也是當用戶發起一個具體的域名請求時DNS伺服器能夠最終找到要聯絡的IP地址的原因。
區域檔案存放在域名伺服器上，通常定義了指定域名下可以訪問的資源或者能否獲得資訊的地方。
Record 記錄
在區域檔案上，還會有record記錄。它的最簡單的形式——一條記錄就是一條從資源到名字的單一對映。這樣可以對映一個域名到一個IP地址，為域名定義名字服務，為域名定義郵件服務等等。
DNS的工作原理
現在你已經對DNS的相關概念已經有個大致的瞭解了，那這套系統究竟是如何運轉的？
從巨集觀上看，這套系統非常的簡單。但是當你仔細去看的時候卻又非常複雜。總之一句話它是當今網際網路採用的非常可靠的基礎設施。
Root Server 根伺服器
正如我們上面所說的，DNS它的核心是一套層級系統。在這套系統的頂層就是我們所稱的根伺服器（root server）。這些伺服器被各種組織所控制，並有ICANN（網際網路名稱與數字地址分配機構）授權。
全球目前有13臺根伺服器。然而，因為每分鐘有無數的名字要處理，所以事實上有很多這些伺服器的映象。有意思的是這些映象伺服器的IP竟然和單根伺服器共享同樣的IP地址。當請求要傳送到一臺根伺服器，這個請求會被路由到最近的映象根伺服器上。
那麼這些跟伺服器都做什麼？根伺服器處理關於頂級域名資訊的請求。因此如果一個請求在低層級的域名伺服器上無法解決，就會查詢域名的根伺服器。
根伺服器實際上並不真的知道域名主機在哪。它們會把請求指向處理指定頂級域名的名字伺服器來處理。
所以如果產生了一個傳送給根伺服器的請求比如"www.wikipedia.org"，根伺服器如果在它的record記錄中沒有找到結果。它會檢查它的區域檔案檢視是否有匹配"www.wikipedia.org"。當然它不會找不到。
相反它會找到一條關於TLD"org"的記錄，然後把org地址的名字伺服器的地址返回。
TLD Server 頂級域名伺服器
請求者然後傳送一條新的請求到新地址（根伺服器提供的），這就是頂級域名對這條請求的響應。
所以，為了繼續我們的這個例子，它會發送一條請求到名字伺服器來響應這個已知的org域名，來檢視是否有"www.wikipedia.org"的下落。
這次，請求者會查詢它的區域檔案。在它的檔案記錄裡還是找不到。
然而，它會找到一條負責"wikipedia.org"這個名字的伺服器的IP地址。現在已經離我們想要的答案又近了一步。
Domain-Level Name Server 域名級名字伺服器
此時此刻，請求者已經有了負責處理這個資源的實際IP的名字伺服器的IP地址。它傳送一條新的氫氣到這個名字伺服器來詢問，看這臺伺服器是否能解決"www.wikipedia.org"。
名字伺服器檢查他的區域檔案，並找到與這個wikipedia.org相關聯的一條區域檔案。在這個檔案中，這裡有一條關於"www"host的記錄。這條記錄裡交待了這個主機的具體IP地址。然後名字伺服器把最終的答案返回給了請求者。
什麼是名字解析伺服器？
在上面的場景裡，我們提到的"請求者"。在這個場景中到底什麼是Requester？
在幾乎所有的例子中，請求者就是我們所謂的"名字解析伺服器"。一臺名字解析伺服器是一臺被配置用來詢問其他伺服器問題的。對於使用者來說它就好比一箇中介，通過快取之前的查詢結果來提高速度，它也知道哪些能夠解決他還不知道的相關請求的根伺服器的地址。
基本上，使用者通常很少在他們的電腦上配置域名伺服器。域名解析伺服器通常是由ISP或者其他組織來提供的。比如你可以查詢Google提供的DNS伺服器。當然這些你可以在你的電腦上自動配置或者手動配置。
當你在瀏覽器的位址列裡輸入一個URL地址時，你的計算機首先檢視本地看資源是否已經定位。它通過檢查計算機上的hosts檔案和一些其他定位檔案。然後發起請求到名字解析伺服器等待接受資源對應的IP地址。
名字解析伺服器器然後檢查檢查它的快取看是否能夠找到答案。如果沒有找到，然後它就會走之前說的那些步驟。
名字解析伺服器通常會為終端使用者壓縮請求處理的進度。客戶端只需要詢問名字解析伺服器資源所在位置，並確信他們會返回最終答案。
Zone File 區域檔案
在上面的過程中我們提到了"Zone File"區域檔案和"record"記錄。
區域檔案是用來給名字伺服器儲存他們所知道的域名資訊的的地方。名字伺服器知道的每一個域名都儲存在一個區域檔案中。對於進入到普通名字伺服器的大多數請求都不需要伺服器通過區域檔案來查詢。
如果它被配置為遞迴查詢，就像一個名字解析伺服器，他會查詢到答案並返回。否則，他會告訴請求方下一步應該去哪裡查。
一個名字伺服器擁有的Zone File 區域檔案越多，他需要應答的請求也就越多。
一個區域檔案描述一個DNS的區域，這是整個DNS域名系統的子集。它通常被用來配置一個單一的域名。它可以包含多條記錄用來定義請求中的域名所對應的資源在哪。
預設情況下Zone中的$ORIGIN是一個引數等價於區域中最高許可權級別。
所以如果一個區域檔案被用來配置一個"example.com."的域名，這個$ORIGIN就要被設定為 example.com. 。
這配置在區域檔案的頂部或者也可以定義在DNS伺服器配置檔案引用區域檔案。無論哪種方式，這個引數都表示了這個Zone檔案代表的檔案。
同樣的，$TTL用來配置"time to live"的資訊。他基本上是一個定時器。用來表示一個快取，名字伺服器可以使用它之前的查詢結果直到TTL時間用完為止。
Record 記錄型別
在一個區域檔案中，我們可以使用不同的記錄型別。一會我們會討論一些常見的型別（或者強制型別）。
SOA 記錄 起始授權，或者SOA記錄，在全部的區域檔案中是強制性記錄。他必須是檔案中的第一個真實的記錄（儘管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. :這是區域的根。這裡指定這個zone檔案是給 domain.com. 這個域名的。當然，經常你會看到這裡會用@，他是一個佔位符替代我們上文中的 $ORIGN。
- IN SOA:"IN"這個部分的意思是internet（在很多記錄中會出現）。SOA是指示符用來用來表示這是一個SOA記錄。
- ns1.domain.com.:這裡定義了這個域名的主名字伺服器。名字伺服器可以是主伺服器或者從伺服器。如果動態DNS被配置，那這裡就需要一臺主伺服器。如果你沒有配置動態DNS，這裡就只是一個你的主名字伺服器。
- admin.domain.com.:這裡是這個zone區域的管理員的email地址。email地址中的@被替代為一個點。如果郵箱地址中有點那麼需要使用一個""反斜槓來替代，比如[email protected]（需要寫成your\name.domain.com)。
- 12083:這個是zone檔案的序列號。每次你編輯一個zone檔案，你必須要要增加一次這個檔案的這個數字讓它正確傳播。從伺服器會檢查主伺服器的zone檔案的序列號是否比他們系統裡現有的序列號大。如果是，它就會請求一個新的zone檔案，否則就繼續使用老的檔案。
- 3h:這個是zone檔案的重新整理間隔週期。從機會等待這個時間週期然後輪詢主機，檢查zone檔案變化。
- 30m: 這是重試zone檔案的間隔時間。如果從機在重新整理時間到達後無法連線主機，他會等待一段時間並重新嘗試輪詢主機。
- 3w: 過期時間。如果一個名字伺服器從機在這個時間段裡無法連線伺服器，它就不能作為這個區域的權威來發揮響應
- 1h: 這個時間段是名字伺服器快取一個名字錯誤的時間量，如果它不能在檔案中找到請求的名字。
A和AAAA記錄
這些記錄都對映一個host到一個IP地址。A記錄是被用來應一個host到一個IPv4的IP地址，而AAAAA記錄則是用來對映一個host到一個IPv6的地址。
這些記錄的常規格式
host IN AIPv4_address host IN AAAA IPv6_address 複製程式碼
我們的SOA記錄呼叫我們的ns1.domain.com的主伺服器。我們需要對映它到一個IP地址，因為ns1.domain.com中的domain.com的zone檔案以及定義了。
這個記錄看起來像下面這樣：
ns1 IN A 111.222.111.222 複製程式碼
注意我們不需要指定全名稱。我們只需要給定host，不需要FQDN，DNS伺服器會自動使用$ORIGIN的值來填充剩餘部分。當然我們也可以簡單的使用FQDN的方式，如果我們喜歡這種語義：
ns1.domain.com.INA111.222.111.222 複製程式碼
在絕大多數情況下，你會定義你的web伺服器名字為www
wwwINA222.222.222.222 複製程式碼
我們還需要說明基礎域名解析到哪，我們可以這樣處理
domain.com.INA222.222.222.222 複製程式碼
我們也可以使用"@"來指代基礎域名
@INA222.222.222.222 複製程式碼
另外我們也可以指定哪些沒有明確指明的服務都解析到什麼地方。我們可以使用"*" 來指代
*INA222.222.222.222 複製程式碼
上面的這些同樣適用於AAAA記錄來配置IPv6地址
CNAME記錄
CNAME記錄定義了一個給定的服務（一個通過A記錄或者AAAA記錄定義的）名字的別名。
例如：我們已經定義了一條A記錄叫server1的host，然後使用www來定義一個這個host的一個別名：
server1INA111.111.111.111 wwwINCNAMEserver1 複製程式碼
需要注意的是這些別名會帶來一些效能上的損失，應為他們需要對伺服器做額外的查詢。絕大多數時候，同樣的結果可以通過使用A或者AAAA記錄來完成。
只有一種情況下推薦使用CNAME，就是為當前區域以外的資源提供別名。
MX記錄
MX記錄是被用來定義域名郵件交換。這可以幫助郵件訊息正確到達郵件伺服器。
不像許多其他的記錄型別，郵件記錄生成不需要對映host到什麼事情上，因為他們使用本Zone，因此他們看起來像這樣：
INMX10mail.domain.com. 複製程式碼
注意開頭沒有host名稱
同時還要注意這裡的一個額外的數字。這個數字是幫助計算機決定傳送到哪臺郵件伺服器如果定義了多臺郵件伺服器的話。數字越低擁有越高的優先順序。
MX記錄通常應該指向一臺A或者AAAA記錄定義的host，而不是用CNAME定義的。
所以，如果我們有兩臺郵件伺服器。那這裡的配置應該像這樣：
INMX10mail1.domain.com. INMX50mail2.domain.com. mail1INA111.111.111.111 mail2INA222.222.222.222 複製程式碼
在這個例子中，mail1的host是首先的郵件交換伺服器。
我們也可以寫成下面這樣
INMX10mail1 INMX50mail2 mail1INA111.111.111.111 mail2INA222.222.222.222 複製程式碼
NS記錄
這個記錄型別定義了名字伺服器被這個zone使用
你可能回想，如果zone檔案放在了名字伺服器，為啥還需要引用他自己？DNS之所以如此的成功，是因為使用了幾多的快取。在zone檔案中定義名字伺服器的一個原因是zone檔案可以被從一個快取拷貝到另一個名字伺服器。當然在自己的名字伺服器上定義名字服務還有其他的原因，但是我們現在還沒有到那一步。
就像MX記錄，這裡是區域範圍引數，所以他們就不用關心host。他們如下
INNSns1.domain.com. INNSns2.domain.com. 複製程式碼
為了在其中一個伺服器出問題時，能夠正確的操作，你可能有兩個名字名字伺服器，每一個都定義了zone檔案。絕大多數DNS伺服器軟體都會把只有單一的名字服務的zone檔案看做是失效的。
通常情況下，都會影殺host到A和AAAA記錄：
INNSns1.domain.com. INNSns2.domain.com. ns1INA111.222.111.111 ns2INA123.211.111.233 複製程式碼
這裡還有一些其他的你能使用的記錄型別，但是上面這些型別應該是你會遇到的最最常用的型別。
PTR記錄
PTR記錄被用來定義一個名字和一個IP地址的關聯。PTR記錄是A和AAAA記錄的反操作。PTR記錄的獨特之處是他們從.arpa根開始，並且被代理給IP地址的擁有者。RIR（Regional Internet Registries）區域網際網路註冊機構管理IP地址代理給組織和服務提供商。RIR包括APNIC，ARIN，RIPE NCC，LACNIC和AFRINIC。
這裡是一個關於111.222.333.444的PTR記錄，看上去像這樣：
444.333.222.111.in-addr.arpa.33692INPTR 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. 複製程式碼
命令列工具dig帶上-x標誌可以用來查詢反向DNS伺服器的IP地址
這裡是一個dig命令的例子。附加的+short是用來減少反向DNS名字輸出的。
$ dig -x 8.8.4.4 +short 複製程式碼
執行上面的那條命令，你會看到PTR記錄對於IP地址所對應的域名
google-public-dns-b.google.com. 複製程式碼
網際網路上的伺服器使用PTR記錄來把域名放到日誌條目中，做出明智的垃圾郵件處理決策，並顯示其他裝置的易讀的詳細資訊。
最大多數常用的郵件伺服器都會查詢PTR記錄在接收郵件的時候。如果來源IP地址沒有PTR記錄的關聯資訊，傳送的郵件會被當成垃圾郵件並被拒接。PTR中的FQDN與正在傳送的電子郵件的域名匹配並不重要。重要的是，存在具有相應且匹配的前向A記錄的有效PTR記錄。
通常網際網路上的網路路由提供對應他們實體地址的PTR記錄。例如你可以看到在紐約和芝加哥引用NYC或者CHI作為路由。這對於執行traceroute或者MTR或者檢視英特網流量所採用的路徑時非常有用。
大多數提供商提供專用服務或者VPS服務會給客戶設定PTR記錄到他們IP地址的能力。
FQDN在PTR記錄中有一個通訊並匹配前向A記錄。 例如111.222.333.444有一個PTR到server.example.com和server.expamle.com有一個指向111.222.333.444的A記錄 複製程式碼
CAA記錄
CAA記錄被用來指定允許CA（證書頒發機構）為你的域名頒發SSL/TLS證書。到2017年9月8日全部的CA都被允許檢查這些記錄在頒發證書前。如果沒有記錄，任何CA都可以頒發證書。否則，是有特定的CA可以頒發證書。CAA記錄能夠被應用到單個host或者整個域名。
下面是一個CAA記錄的例子：
example.com.INCAA 0 issue "letsencrypt.org" 複製程式碼
host,IN和記錄型別CAA在DNS欄位中很普遍。上面的CAA資訊是 0 issue "letsencrypt.org" 的一部分。它有三部分組成：flags(0),tags(issue)和values("letsencrypt.org")。
- Flags 是一個整數，用來指示CA應該處理它不理解的tags。如果flag為0，記錄會忽略。如果值為1，CA必須決絕簽發證書。
- Tags 是字串表示CAA記錄的目的。目前，他們可能有權授權CA為特定主機名建立證書，isswild授權萬用字元證書，或者iodef定義CA可以報告策略違規的URL。
- Values 是一個字串關聯到一個tag記錄。對於issue和issuewild這通常是你授予許可權CA的域。對於iodef，這可能是聯絡人表單的URL或者一個到反饋郵件的mailto:的連結。
你可以用使用 dig 來發去CAA記錄使用下面的選項：
$ dig example.com type257 複製程式碼
對於更多的關於CAA記錄的資訊，你可以閱讀 RFC6844