打印机,亚洲国产成人片在线观看,亚洲VA久久久噜噜噜久久天堂

目錄：

一些基本概念
- 主機名
- DNS
- 名稱解析
  - DNS 解析的后端存儲
  - 名稱解析總結
大規(guī)模域名解析的體系架構
- DNS 解析需要分布式的架構
  - 早期使用本地 hosts 文件解析方式
  - 中期由中心 DNS 服務器提供 hosts 文件
  - 域名解析查找結果被緩存，以減輕服務器壓力
  - 域名解析進入分布式階段
真正域名查詢的過程
DNS 中涉及的概念詳解
- DNS正向解析，反向解析
- DNS 的 zone(區(qū)域解析庫)
- 區(qū)域解析庫詳解（zone）
- 主DNS服務器/權威DNS服務器是怎么工作的
  - DNS 服務器負責本地域內(nèi)主機名的解析
  - DNS 服務器如何處理非本地域名的解析
- DNS客戶端進行域名解析的流程
  - 非權威應答
  - 緩存DNS服務器
  - DNS 轉發(fā)器
- 輔助(從)DNS服務器
  - 主從服務器間的區(qū)域傳送
  - 完全區(qū)域傳送
  - 增量區(qū)域傳送
- 區(qū)域解析庫中的資源記錄類型

一些基本概念

主機名

www.magedu.com: 這是一個常見的網(wǎng)站主機名，這個名稱被稱為：FQDN - Full Qualified Domain Name

DNS

DNS：Domain Name Service - 域名解析服務

DNS 也是 C/S 架構的，有客戶端、服務器兩個部分。

服務器端一般是 BIND，BIND - Berkley Internet Name Domain
客戶端一般是共享庫 - 由其他應用調(diào)用

DNS端口: 53/udp, 53/tcp

主機名和域名是不同的:

www.magedu.com - 這是主機名
.magedu.com. - 這是域名

名稱解析

名稱解析是什么：名稱解析 - 把一種名稱轉換為另一種名稱。
名稱是一個“字符串” <—-> “數(shù)字” 相互轉換

DNS 解析的后端存儲

DNS 的解析，在背后依靠解析庫進行轉換。在“某種存儲”中，存儲了每一個“名稱”和“數(shù)字”的對應關系。

“某種存儲” 指不同格式的存放：

1，文本文件

缺陷，當文本信息過大時，如 100w 條信息，這時查找一條信息是非常低效的。所以文本文件不適合大量數(shù)據(jù)的存儲，因為檢索效率不好。

另一方面，文本文件過大時，因為需要將整個文件載入內(nèi)存中，這也很可能造成性能問題(大量 I/O 操作)。

2，關系型數(shù)據(jù)庫 - 支持索引，快速的檢索效率

它把“搜索鍵值”單獨抽取出來，即“索引”，單獨做成小型數(shù)據(jù)庫用于檢索，查找時，只需要查找到“索引”，即可返回對應的查找條目。

“索引” 可看做一條信息的 “特征信息”，與 “hash特征碼” 的思路有點類似。它指向?qū)哪且粭l信息在文件中的存儲位置(磁盤 block，因為文件以 block 為單位存放數(shù)據(jù))。

關系型數(shù)據(jù)庫仍然存在的問題，即當數(shù)據(jù)達到“百萬”、“千萬”、“上億”的級別時，索引文件就變成很大，其效率并不一定會很理想。

有時為提高效率，會給索引再作一次索引(將一定范圍內(nèi)的索引，做成一個索引)，乃至多級索引，以減小索引文件的大小，以提高檢索的效率。

索引有“稠密”索引和“稀疏”索引之分

“稠密”索引 - 每一條數(shù)據(jù)對應一條索引
“稀疏”索引 - 比如二級索引，將100條一級索引做成一個索引，相當于劃分段落。

3，LDAP

比關系型數(shù)據(jù)庫的索引檢索效率，高不止一個數(shù)量級的：

LDAP: Lightweight Directory Access Protocol, 389/tcp

LDAP 尤其適用于 “用戶名” 檢索。

名稱解析總結

所以，解析庫，就是以某種合適的方式存儲“鍵值對”信息的數(shù)據(jù)庫(文本文件、關系型數(shù)據(jù)
庫、LDAP 等等)

解析: 根據(jù)用戶提供的名稱，去查詢(以名稱為“鍵值”)解析庫，最終得到期望得到的另一
種名稱，這一過程被稱為“解析”的過程。

對客戶的而言，這一過程，是查詢請求，對于服務端，是將查詢結果返回給客戶端。
這就是“名稱解析”的概念。

大規(guī)模域名解析的體系架構

互聯(lián)網(wǎng)上的域名的數(shù)量的規(guī)模之大(100億+)，放在什么存儲里面合適呢? 解析的速度怎么提升? 而且全球?qū)τ谟蛎馕龅恼埱蠛纹涠啵趺错憫恳粋€請求呢？

每秒100w的請求，能夠支撐嗎? 什么是解析過程，DNS 背后的工作機制是怎樣的?

有多個用戶請求時，進程是怎么響應的呢？這也就是并發(fā)用戶請求的概念，有很多用戶，很多請求，同時連接到當前主機上來。每一個請求都要去響應的。

DNS 解析需要分布式的架構

一般來講，進程需要用一個建立連接的套接字，而非監(jiān)聽的套接字來響應請求。早期的并發(fā)用戶響應模型，都是使用“進程”來響應的。來一個用戶請求，啟動一個進程響應該用戶的請求，有多個用戶，就啟動多個進程響應請求。如果有100w個用戶請求進來會發(fā)送什么情況呢？假設一個進程需要 “5M” 內(nèi)存，100w個請求，需要100w個進程，
需要的內(nèi)存就是 “500萬M” 內(nèi)存。這對于一臺服務器是不可能的，任何一臺服務器，都不可能滿足互聯(lián)網(wǎng)上名稱解析請求的要求。

所以，這些請求，將他們分散至多個不同服務器上，才能承擔起這個量級的壓力。

這即是分布式的應用

進一步的，分布式的每個服務器，存儲的是整個互聯(lián)網(wǎng)的“名稱解析”數(shù)據(jù)，還是一部分呢。如果是一部分，怎么把用戶請求，路由到正確的位置(存儲了跟請求的名稱相關數(shù)據(jù)的服務器)？這些都是 “DNS” 需要解決的問題。

早期使用本地 hosts 文件解析方式

在早期來說，互聯(lián)網(wǎng)上的主機數(shù)量還不多的時候，因為IP地址難以記憶，所以催生了對于“主機名” 的需求，人們希望使用“主機名” 與服務器通信。而在那時，完成這個工作的實現(xiàn)方式，是在本地的文件中存放 “IP地址” 與 “目標主機名” 的對應關系，這個文件就是“hosts” 文件。

最初的互聯(lián)網(wǎng)發(fā)展速度很慢，幾年之間，也不過增加百十來臺服務器，所以通過文本文件記錄這些信息仍然足夠使用。但到后來，互聯(lián)網(wǎng)上的服務器開始成倍增加時，就需要一種更好地方式來管理 ”主機名” 和 “IP地址” 之間的關系了。

中期由中心 DNS 服務器提供 hosts 文件

IANA: 負責互聯(lián)網(wǎng)地址分配，管理互聯(lián)網(wǎng)上 ”主機名” 和 “IP地址” 對應關系。早期的實現(xiàn)，是將解析庫（文本文件)通過 ftp 發(fā)布出來。各地的Unix主機管理員，需要設定任務計劃，去定時的獲取解析庫文件到本地，實時更新。

客戶端應用當有名稱解析的請求時，通過調(diào)用 DNS客戶端的”共享庫”(現(xiàn)在已經(jīng)成為 glibc 標準庫的一部分)，去本地的 hosts 文件獲取到希望獲取的解析結果。

后來，由 ftp 共享文件的方式，發(fā)展到 DNS(這時還是一個中心服務器)，使用了高可用集群避免其中一臺當機使整個服務中斷。這時本地應用有名稱解析的需求時，會通過調(diào)用DNS共享庫，除了向本地hosts查詢以外，也向中心服務器開放監(jiān)聽端口發(fā)起請求，服務器啟動一個進程響應請求，進行查詢后，返回結果給本地應用。這兩種方式，都保留了下來，而且會優(yōu)先查詢本地的 hosts 文件。

我們需要 DNS 快速相應請求，默認使用 UDP 協(xié)議(不需要3次握手建立連接)。

域名解析查找結果被緩存，以減輕服務器壓力

我們客戶端每一次都用主機名發(fā)起請求，是不是每一次都需要向 DNS 服務器請求進行名稱解析呢，不是的，因為IP地址并不經(jīng)常變動的。所以本地DNS客戶端可以將解析結果存儲在本地，建立緩存(內(nèi)存中的存儲空間)。意味著，只有第一次查詢時，才需要去DNS服務器取得解析數(shù)據(jù)。我們后面發(fā)起請求，會首先檢查緩存中是否有結果，沒有，才會去向DNS服務器請求。所以緩存在這里，既可以加速我們的訪問，又能減輕DNS服務器的壓力。假設我們的緩存有效期是1小時，在1小時發(fā)起的請求是20個，那么在一小時內(nèi)，向DNS服務器請求的次數(shù)就減少到1次，也即是20倍，所以壓力減輕的效果是尤其明顯的。

隨著互聯(lián)網(wǎng)的發(fā)展，即使有本地緩存等技術減輕DNS服務器的壓力，但是漸漸地一臺中心服務器已經(jīng)難以應付這個工作，這是DNS服務器就進入了下一個階段：將名稱實現(xiàn)分布式應用。

域名解析進入分布式階段

將名稱實現(xiàn)分布式應用:

將整個互聯(lián)網(wǎng)的主機名，劃分成多個不同的部分
整個名稱空間，被劃分多個自治的完整的小空間。如同國家的行政劃分，中央 —-> 省 —-> 市

DNS也采用了這種機制：授權管理機制。

最上層的區(qū)域：根域 - Root Domain
根域下面是“一級域”：Top-Level Domain
再下一層是扁平化管理的：二級域，公司，組織或個人可直接申請
最后一層，可以直達主機了

“根域” 和 “一級域” 是由“IANA”直接管理。
二級域，公司，組織或個人可直接申請。二級域申請好之后，在這個域內(nèi)就可以建立主機了。

組織和公司里通常“約定俗成”地使用 “www” 為主機名。

整個名稱，是自底向上，逐級追溯的模式。

DNS 是一個樹狀的結構：

Snip20160730_8.png

在“根域”這里，只關心“一級域名”的情況，記錄了如 com、net、org 這幾個域名分區(qū)的負責人的信息。

這里有兩種查找模型：

1，層級遞歸查詢

A -> B -> C -> D

A 問 B，B不知道，但 B 知道 C 知道，于是B問C，C也不知道，但C知道D知道。
逐級查詢，逐級返回。

2，迭代查詢

A -> B
A -> C
A -> D

A 問 B，B不知道，但 B 知道 C 知道，于是A去問C，C也不知道，但C知道D知
道，于是A去問D。

真正的DNS查詢使用的哪種模式? 互聯(lián)網(wǎng)上的絕大多數(shù)查找模型都是迭代的。但 DNS 是遞歸+迭代的，是先遞歸，后迭代的。

真正域名查詢的過程

真正域名查詢的過程是: 先遞歸，后迭代。

比如當客戶端查詢 www.qq.com 的時候，不是直接去找根的，你想一下配置網(wǎng)絡地址時，你的DNS服務器填寫的是什么，一般是本地的一個服務器，可能是公司內(nèi)部的一個服務器，如果公司沒有，你的寬帶運營商一定會提供一個DNS服務器地址。

在DNS的模型中，上級知道下級，但下級不知道自己的上級是誰，雖然知道自己在哪個域名內(nèi)，但那個域名的管理者(服務器)是誰，其實是不知道的。

當我們請求域名解析時，把請求發(fā)送到本地的某個DNS服務器，如果是請求解析 “www.qq.com”，當DNS服務器要查詢一個非本地管理的域名時，會去找“根”。每一個DNS服務器都預先設置了“根”的地址，大部分默認法則，它們僅知道”根”的IP地址，并不知道其他一級域名管理者的地址。

“根” 返回說查詢的主機名歸 com 管理，返回 com 的管理者地址，本地的DNS服務就去 com 的服務器進行查詢。com 返回說歸 qq.com 的二級域名管理者管理，于是本地DNS又去查詢 qq.com 這個域名的管理者的域名服務器，最終得到 www.qq.com 的IP地址，返回給客戶端。

客戶端到本地 DNS 這一步，是“遞歸查詢”的方式，要求 DNS 服務器必須返回結果，只發(fā)出一次請求。DNS 服務器進行查詢的方式，是“迭代查詢”的方式，可能多次發(fā)起查詢請求。

全球的根節(jié)點服務器是固定的，一共有13個，國內(nèi)連根服務器的鏡像都沒有。

比較常見的頂級域：

組織域：.com , .org, .net, .mil, .edu, .gov
國家域：.cn, .us, .uk, .jp, .tw, .hk
反向域：.in-addr.arpa - 從IP地址解析成主機名稱時使用

組織域、反向域，由IANA管理。
國家域，由各國統(tǒng)一的DNS服務商來管理。

DNS 涉及的概念詳解

DNS 中的名稱與對應主機的“主機名”不要求是一樣的，注意它們不是同一個概念。

在 DNS 中：
一個“名稱”可以對應多個IP(即有多個主機)
一個IP上也可以有多個“名稱”

DNS正向解析，反向解析

1，F(xiàn)QDN —-> IP地址
2，IP地址 —-> FQDN

一開始，反向解析幾乎不可能，后來利用特殊技術才能做到。

國內(nèi)一般都沒有配置“反向解析”，但是，郵件服務器必須配置反向解析，否則會認為你是垃圾郵件。

DNS 的 zone（區(qū)域解析庫）

域：domain
區(qū)域：zone(解析庫)

正向解析：FQDN —-> IP地址，依賴于解析庫 - 一個解析庫是一個 zone（區(qū)域）
反向解析：IP地址 —-> FQDN，依賴于反向解析庫

域中包含一個或兩個區(qū)域(zone)，或者說是解析庫。

區(qū)域解析庫詳解（zone）

在解析庫中，每一個行是一個解析條目，叫做“資源記錄” - resource record（rr）。

資源記錄有類型的概念，用于表示解析條目的屬性，下面依次說明:

NS（Name Server）
本區(qū)域的“名稱服務器”，負責本地域內(nèi)主機的 DNS 解析，可能有多個。

SOA（Start of Authority）
起始授權記錄：用來標記區(qū)域內(nèi)的 DNS主服務器 是誰，主服務器一個區(qū)域內(nèi)只能有一個。

MX（Mail eXchage）
郵件交換器

當我們發(fā)郵件時，比如：tom@163.com - 163.com 是域名，tom在域內(nèi)的哪個服務器上呢？MX 是域內(nèi)負責郵件接收的服務器。假設域內(nèi)有多個 MX，那tom在哪個服務器上呢？實際上，tom用戶在每一個 MX 服務器上都有記錄，而這多個 MX 服務器，有優(yōu)先級的區(qū)分（0-99），數(shù)字越小，優(yōu)先級越高。

A
FQDN—->IP ：A，負責“正向名稱解析”

PTR
IP地址 —-> FQDN：PTR，負責“反向名稱解析”

AAAA
FQDN—->IPv6：AAAA，負責IPv6地址的“正向名稱解析”

CNAME（Canonical Name）
正式名稱：CNAME（Canonical Name），正式名稱

A CNAME B: A 的正式名稱是 B

總結一下，解析庫中的條目的類型有：NS,SOA,MX,A,PTR,AAAA,CNAME 等

主DNS服務器/權威DNS服務器是怎么工作的

我們申請了一個域名之后，需要為這個域建立一臺DNS服務器，來負責這個域內(nèi)的所有主機名的解析。這個DNS服務器就是這個域的“權威DNS服務器”，除了這臺DNS服務器，沒有其他人知道該域內(nèi)的主機的解析名。一個域內(nèi)可以有備用的DNS服務器，但主服務器只能有一個。

DNS 服務器負責本地域內(nèi)主機名的解析

假設我們注冊了域名：magedu.com, 意味著我們要負責對該域名內(nèi)的所有主機進行“名稱解析”。要解析，就得有解析庫，要找一臺主機來負責存放解析庫，并負責響應對于該域名內(nèi)的主機名的“解析請求”。如果本地主機發(fā)起一個請求，假設本地的DNS服務器的主機名叫做 ns.magedu.com，客戶端向 ns 主機請求 www.magedu.com 的解析地址，這個主機名的解析是不是就是由 ns 這臺服務器負責呢？假如這個域內(nèi)只有這一臺 DNS 主機，很顯然這個域內(nèi)的所有主機，只有這臺 ns 主機才能知道。

這臺ns主機會負責，本地的所有“名稱解析”請求，或來自網(wǎng)絡的對于本域的查詢請求。

這臺ns主機的IP地址，需要注冊到上級服務器。

這臺DNS服務器，被稱為“主DNS服務器”。

DNS 服務器如何處理非本地域名的解析

如果客戶端向 ns 主機請求 www.ibm.com 的解析地址，如果 ns 本地沒有緩存的話，就向根域詢問，這個根的地址是預先存放在ns主機上的，然后按照上面講述過的步驟，進行查詢。全球有13個根節(jié)點，在向根查詢的時候，是向誰查詢的呢？根域 . 這個名稱對應了 13 個IP地址，ns 主機默認是輪流去查詢的。同理，.com 服務器也不止一個（為了實現(xiàn)冗余或備份的效果），根在返回 .com 的地址時，也會輪流返回其中一個，或者全部返回了，ns 也只是選擇第一個地址。同理，ibm.com 域名服務器也可能不止一個，.com 或者輪流返回其中一個，或者全部返回，ns 主機也同樣選擇其中第一個地址。

DNS客戶端進行域名解析的流程

客戶端進行域名解析的流程：

先查hosts文件
若沒有，查本地DNS緩存
若沒有，再查DNS服務器：
- 先查DNS服務器的本地DNS緩存
- 若沒有，再查DNS服務器的解析庫
- 都沒有，那DNS向根域發(fā)起請求，開始迭代查詢

如果緩存的有效期為1天的話，能極大減輕DNS服務器的壓力，所以對于DNS的架構，“緩存”是很重要的。

非權威應答

如果通過緩存返回名稱解析的請求，由于緩存與實際的情況存在時間差，所以被稱為：“非權威應答”

緩存DNS服務器

那本地的DNS服務可不可以只做一半的工作呢，比如不負責“本地域內(nèi)主機名”的解析，只負接收本地客戶端的“名稱解析”請求，然后向根發(fā)起迭代查詢，以及對查詢結果進行緩存。答案是可以的。

這樣做的好處是什么呢，好處在于這個緩存，一個域名進行一次查詢之后，緩存在服務器上，本地的其他客戶端請求同一個域名的解析時，可以通過緩存的結果進行響應，這就可以加快本地客戶端的名稱解析速度，減輕網(wǎng)絡帶寬的壓力。這種服務器，被稱為“緩存DNS服務器”。

DNS 轉發(fā)器

還有一種DNS服務器，只負責轉發(fā)DNS請求，轉發(fā)給另一臺DNS主機做查詢，本地不做緩存，稱為“轉發(fā)器”。

輔助(從)DNS服務器

主從服務器間的區(qū)域傳送

輔助DNS服務器的用處，是冗余和備用。備用的可以有多個，它有和主服務器同樣的“解析庫”，它會去同步主服務器上的解析庫，這個同步過程(傳送zone文件)，被稱為“區(qū)域傳送” - zone transfer，它是單向的，所有的修改，只能在 DNS 主服務器上進行。

從服務器有多個的時候，一個從服務器可從另一個從服務器獲取“區(qū)域文件”。這是多級從服務器。

完全區(qū)域傳送

第一次傳送區(qū)域文件，通常是傳送完整的區(qū)域文件，這叫做“完全區(qū)域傳送” - axfr

增量區(qū)域傳送

后續(xù)傳送區(qū)域文件，通常是傳送增量的區(qū)域文件，這叫做“增量區(qū)域傳送” - ixfr

區(qū)域文件，一方面是定期由從服務器去向主服務器詢問和拉取。一方面當主服務器發(fā)生更新，會向從服務器發(fā)送更新通知，讓從服務器來拉取。

而且傳送區(qū)域文件，為了保證文件的完整性，使用的是 TCP 協(xié)議進行傳輸。前面我們知道 DNS 工作在 TCP 和 UDP 協(xié)議下，UDP 是負責監(jiān)聽查詢請求的。

如果主服務器出現(xiàn)問題，不響應從服務的詢問，經(jīng)過一段時間的嘗試，發(fā)現(xiàn)仍然沒有響應，從服務器就不再對DNS請求做應答，放棄解析。從服務器不會取而代之，而是在必要時提供冗余的能力。

區(qū)域解析庫中的資源記錄類型

在區(qū)域解析庫中，資源記錄的格式如下：

Name [ttl]  IN  RRType  VALUE

分別為：名稱,有效緩存時間,固定字段,資源記錄類型,值

在解析庫中，如果定義了變量 $TTL, 那么在每一條資源記錄中，可以不寫 ttl。如果想定義不同的ttl，仍然可以寫出來，它會覆蓋 $TTL 的值。

任何解析庫文件的第一條記錄必須是SOA，SOA是用于標記域內(nèi)的主服務器是誰。

SOA: Start of Authority

name: 當前區(qū)域名稱,通常可以簡寫為 "@"；
ttl: 略
RRTtype: SOA
VALUE: 主 DNS 服務器的名稱（FQDN），也可以是當前區(qū)域的區(qū)域名稱；這里為 ns.magedu.com；

例如：

@ IN SOA ns.magedu.com. admin.magedu.com. (
    serial number   ; 解析庫的版本號，例如：2014080401(分號是注釋)
    refresh time    ; 周期性同步的時間間隔(從服務器的同步時間)
    retry time      ; 重試的時間間隔(主不響應時，從服務器的重試時間間隔)
    expire time     ; 過期時長(從服務器的過期時間)
    nagtive answer ttl  ; 查無此人時，會給出否定答案，這是否定答案的緩存時長
    )

注意在解析庫文件內(nèi)，域名最后的’.’不能省略。
admin.magedu.com.是 DNS 服務器管理員的郵箱地址，因為 @ 字符在 DNS 配置文件中有特殊意義，不能直接在郵箱地址中使用，所以這里用’.’取代。

NS: name server

例如:

@ IN NS ns.magedu.com.

注意：

如果有多臺NS服務器，每一臺都必須有對應的 NS 記錄，否則不會被識別為 DNS 服務器。
對于“正向解析文件”來講，每一個 NS 的 FQDN 都應該有一個A記錄

MX: Mail eXchanger

例如：

@ IN MX 10 mail.magedu.com.
@ IN MX 20 mail2.magedu.com.

注意：

如果有多臺 MX 服務器，每一臺都必須有對應的MX記錄，但各個MX記錄還有優(yōu)先級屬性。
但是注意，如果第一個MX服務器還能響應，就不會找第二個。
對于“正向解析文件”來講，每一個 MX 的 FQDN 都應該有一個A記錄。

A: Adress

A 記錄

例如：

www.magedu.com. IN A 10.0.0.2
www.magedu.com. IN A 172.0.0.3

pop3.magedu.com. IN A 10.0.0.10
imap.magedu.com. IN A 10.0.0.10

同一個名字可以有多個地址，可以實現(xiàn)類似于負載均衡的效果。

同一個IP可能對應多個名稱，比如一臺服務器同時提供多種服務的情況。

AAAA: IPv6

其他同上

CNAME: 正式名稱是什么

一個 FQDN 的正式名稱是另一個 FQDN。

例如，一個IP地址對應多個名稱，還可以這樣寫:

www.magedu.com. IN A 10.1.1.5
web.magedu.com. IN CNAME www.magedu.com.

這里表示：web.magedu.com. 的正式名稱是 www.magedu.com.

這里為什么不直接寫IP地址呢，假設一個主機有十個別名，如果主機的 IP 地址改變了，只需要改一次就行了，就好像BASH里變量的作用。

有別名這種機制，在 CDN 上做 C 類應用時，提供一個公共 CDN 時，通常都是通過別名的方式指定的：比如訪問的是 www.magedu.com. ，背后卻指向一個CDN的名字。

PTR: pointer 反向解析

例如 172.16.100.9/16，網(wǎng)絡地址是 172.16，主機地址是 100.7，那么，這里的 name 就是 “7.100.in-addr.arpa.”，注意最后有’.’。

value: FQDN

例如：

7.100.in-addr.arpa. IN PTR www.magedu.com.

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

DNS 服務原理詳解

DNS 服務原理詳解

一些基本概念

主機名

DNS

名稱解析

DNS 解析的后端存儲

名稱解析總結

大規(guī)模域名解析的體系架構

DNS 解析需要分布式的架構

早期使用本地 hosts 文件解析方式

中期由中心 DNS 服務器提供 hosts 文件

域名解析查找結果被緩存，以減輕服務器壓力

域名解析進入分布式階段

真正域名查詢的過程

DNS 涉及的概念詳解

DNS正向解析，反向解析

DNS 的 zone（區(qū)域解析庫）

區(qū)域解析庫詳解（zone）

主DNS服務器/權威DNS服務器是怎么工作的

DNS 服務器負責本地域內(nèi)主機名的解析

DNS 服務器如何處理非本地域名的解析

DNS客戶端進行域名解析的流程

非權威應答

緩存DNS服務器

DNS 轉發(fā)器

輔助(從)DNS服務器

主從服務器間的區(qū)域傳送

完全區(qū)域傳送

增量區(qū)域傳送

區(qū)域解析庫中的資源記錄類型

推薦閱讀更多精彩內(nèi)容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

DNS 服務原理詳解

一些基本概念

主機名

DNS

名稱解析

DNS 解析的后端存儲

名稱解析總結

大規(guī)模域名解析的體系架構

DNS 解析需要分布式的架構

早期使用本地 hosts 文件解析方式

中期由中心 DNS 服務器提供 hosts 文件

域名解析查找結果被緩存，以減輕服務器壓力

域名解析進入分布式階段

真正域名查詢的過程

DNS 涉及的概念詳解

DNS正向解析，反向解析

DNS 的 zone（區(qū)域解析庫）

區(qū)域解析庫詳解（zone）

主DNS服務器/權威DNS服務器是怎么工作的

DNS 服務器負責本地域內(nèi)主機名的解析

DNS 服務器如何處理非本地域名的解析

DNS客戶端進行域名解析的流程

非權威應答

緩存DNS服務器

DNS 轉發(fā)器

輔助(從)DNS服務器

主從服務器間的區(qū)域傳送

完全區(qū)域傳送

增量區(qū)域傳送

區(qū)域解析庫中的資源記錄類型

推薦閱讀更多精彩內(nèi)容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频