內部公開▲DNS 域名解析原理（轉帖）從應用的角度上看，對DNS 的訪問是通過一個地址解析器（resolver ）來完成的。在Unix 該解析器主要是通過兩個庫函數(shù)gethostbyname(3) 和

內部公開▲

DNS 域名解析原理（轉帖）

從應用的角度上看，對DNS 的訪問是通過一個地址解析器（resolver ）來完成的。在Unix 該解析器主要是通過兩個庫函數(shù)gethostbyname(3) 和gethostbyaddr( 3 )來訪問 的，它們在編譯應用程序時與應用程序連接在一起。前者接收主機名字返回I P地址，而后者 接收IP 地址來尋找主機名字。解析器

通過一個或多個名字服務器來完成這種相互轉換。

DNS 基礎

DNS 的名字空間和Unix 的文件系統(tǒng)相似，也具有層次結構。

每個結點（如noao 就是一個節(jié)點）有一個至多63個字符長的標識。這顆樹的樹根是沒有任何標識的特殊結點。命名標識中一律不區(qū)分大寫和小 寫。命名樹上任何一個結點的域名就是將從該結點到最高層的域名串連起來，中間使用一個點“.”分隔這些域名（注意這和Unix 文件系統(tǒng)路徑的形成不同，文 件路徑是由樹根依次向下的形成的）。域名樹中的每個結點必須有一個唯一的域名，但域名樹中的不同結點可使

用相同的標識。

以點“.”結尾的域名稱為絕對域名或完全資格的域名FQDN （Full Qualified Domain Name），例如sun.tuc.noao.edu .。如果一個域名不以點結尾，則認為該域名是不完全的。 如何使域名完整依賴于使用的DNS 軟件。如果不完整的域名由兩個或兩個以上的標號組成， 則認為它是完整的；或者在該域名的右邊加

入一個局部后綴。例如域名s u n通過加上局部后綴.tuc.noao.edu. 成為完整的。

所以設置 DNS是要注意 完全資格的域名 和不完整的域名 的區(qū)別，很多 DNS服務器的控制面板都是這樣的，比如eNom 的MX 設置 需要在 域名后 加一個局部后綴 "." 使其成為 FQDN 未命名樹

根 （）

頂級域 arpa com edu gov int mil net org biz info ae..us..zw

頂級域名分為三部分：

1)arpa是一個用作地址到名稱轉換的特殊域

2）3字符長的普通域（組織域）

3）2字符的國家域（地理域）

解析

正向解析，IPv4的地址正向解析的資源記錄是"A"

反向解析，IPv4反向解析的記錄是“PTR”（指針記錄)

DNS 中一直難于理解的部分就是指針查詢方式，即給定一個IP 地址，返回與該地址對應的域名。 首先 查看一下 頂級域 arpa，及它下面的in-addr 域。當一個組織加入Internet ，并獲得DNS 域名空間的授權，如noao.edu ，則它們也獲得了對應IP 地址 的in-addr.arpa 域名空間的授權。在noao.edu 這本文所有信息為中興通訊股份有限公司內部信息，未經允許，不得外傳 第1頁，共7頁

內部公開▲ 個例子中，它是網絡號為140.252的B 類網絡。在DNS 樹中結點in- addr.arpa的下一級必須是該IP 地址的第一字節(jié)（例中為140），再下一級為該IP 地址的下一個字節(jié)（252），依此類推。但應牢記的是DNS 名 字是由DNS 樹的底部逐步向上書寫的。這意味著對于IP 地址為140.252.13.33的sun 主機，它的DNS 名字為 33.13.252.140.in-addr.arpa。必須寫出4字節(jié)的IP 地址，因為授權的代表是基于網絡號： A類地址是第一字節(jié)，B 類地址是第一、二字節(jié)，C 類地址則是第一、二、三字節(jié)。IP 地址的第一字節(jié)一定位于in-addr 的下一級，但FQDN 卻是自樹底 往上書寫的。如果FQDN 由頂往下書寫，則這個IP 地址的DNS

名字將是arpa.in-addr.140.252.13.33，而它所對應的域名將是 edu.noao.tuc.sun。

如果DNS 樹中沒有獨立的分支來處理這種地址—名字的轉換，將無法進行這種反向轉換，除非從樹根開始依次嘗試每個頂級域。毫不夸張地說， 這將需要數(shù)天或數(shù)周的時間。雖然反寫IP 地址和特殊的域名會造成某些混亂，但in-addr 解決方案仍是一種最有效的方式。只有在使用host 程序或 tcpdump程序直接同DNS 打交道時，才會擔心in-addr 域和反寫IP 地址影響我們。從應用的角度上看，正常的名字解析器函數(shù)（ gethostbyaddr ）將接收一個IP 地址并返回對應主機的有關信息。反轉這些字節(jié)和添加in-addr.arpa

域均由該函數(shù)自動完成。

在反向解析的命名空間中, 所有的 IP 組成一個叫作 arpa.in-addr 的 頂級域, 然后再按 IP 層層細分 比如 166.111.4.100 ，我們可以在負責 4.1111.166.in-addr.arpa(注意是過來寫, 因為 頂級域 要在最后

面) 這個 子域名 的機器上, 可以查到其 映射表 上有一個記錄是 100

在PHP 中也有兩個跟C 中一模一樣的函數(shù)可以調用

運行這段腳本，就可以 顯示 www.tsinghua.edu.cn 哈哈，這是清華大學的web 服務器

實際過程放大到這里： Asking e.root-servers.net for 100.4.111.166.in-addr.arpa PTR record:

e.root-servers.net says to go to figwort.arin.net.

(zone: 166.in-addr.arpa.)

Asking figwort.arin.net. for 100.4.111.166.in-addr.arpa PTR record:

figwort.arin.net [192.42.93.32] says to go to dns.tsinghua.edu.cn.

(zone: 111.166.in-addr.arpa.)

Asking dns.tsinghua.edu.cn. for 100.4.111.166.in-addr.arpa PTR record:

dns.tsinghua.edu.cn [166.111.8.30] says to go to dns.cic.tsinghua.edu.cn.

(zone: 4.111.166.in-addr.arpa.)

Asking dns.cic.tsinghua.edu.cn. for 100.4.111.166.in-addr.arpa PTR record:

Reports www.tsinghua.edu.cn. [from 166.111.4.5]

Answer:

本文所有信息為中興通訊股份有限公司內部信息，未經允許，不得外傳 第2頁，共7頁

內部公開▲ 166.111.4.100 PTR record: www.tsinghua.edu.cn. [TTL 86400s] [A=166.111.4.100]

不過gethostbyaddr 很難由IP 得出主機名，這是因為電信（比如上海電信） 他們沒有作 各個IP 對于的主機名，其實的確很難作的，對于流動性很強的IDC 機房和ADSL 用戶IP ，的確沒有對應的主機名

比如，我們查im286.com

Asking e.root-servers.net for 211.251.152.61.in-addr.arpa PTR record:

e.root-servers.net says to go to ns1.apnic.net.

(zone: 61.in-addr.arpa.)

Asking ns1.apnic.net. for 211.251.152.61.in-addr.arpa PTR record:

ns1.apnic.net [202.12.29.25] says to go to nns.sta.net.cn.

(zone: 152.61.in-addr.arpa.)

Asking nns.sta.net.cn. for 211.251.152.61.in-addr.arpa PTR record:

nns.sta.net.cn [61.152.82.18] says to go to ns2.edatahome.com.

(zone: 211.251.152.61.in-addr.arpa.)

Asking ns2.edatahome.com. for 211.251.152.61.in-addr.arpa PTR record:

ns2.edatahome.com [202.109.72.188] says to go to ns1.edatahome.com.

(zone: 211.251.152.61.in-addr.arpa.)

Asking ns1.edatahome.com. for 211.251.152.61.in-addr.arpa PTR record:

ns1.edatahome.com [202.109.72.189] says to go to ns.sta.net.cn.

(zone: 152.61.in-addr.arpa.)

Asking ns.sta.net.cn. for 211.251.152.61.in-addr.arpa PTR record:

ns.sta.net.cn [202.96.199.133] says to go to ns2.edatahome.com.

(zone: 211.251.152.61.in-addr.arpa.)

暈倒了，ns.sta.net.cn 和ns1.edatahome.com 和ns2.edatahome.com 這3個白癡相互推諉

就是說找不到 61.152.251.211 對應的主機名了

本文所有信息為中興通訊股份有限公司內部信息，未經允許，不得外傳 第3頁，共7頁

內部公開▲ 有兩點需要說明的是： 1.負責正向解析（forward mapping） 和 反向解析（reverse mapping） 的DNS 服務器不一定是同一臺 即使是同一臺， 如果不注意的話, 兩邊的內容可能也可能有不匹配的情況

2.domain 與ip 子網并沒有一對一的關系 如清華大學的 domain是tsinghua.edu.cn ， 但是它的IP

子網有多個,166.111是最古老的一個而已

zone

談到了解析和域名之后，應該說說zone 了。

所謂 zone 就是把一個 domain 扣掉 分給下層域 負責的部份, 剩下來的就是 zone.就是一個

domain ，可能會將sub domain授權給下級的 DNS服務器去解析。 準確的說，一個獨立管理的DNS 子樹稱為一個區(qū)域( zone )。一個常見的區(qū)域是一個二級域，如 noao.edu。許多二級域將它們的區(qū)域劃分成更

小的區(qū)域。例如，大學可能根據不同的系來 劃分區(qū)域，公司可能根據不同的部門來劃分區(qū)域。 如果你熟悉Unix 的文件系統(tǒng)，會注意到DNS 樹中區(qū)域的劃分同一個邏輯Unix 文件 系統(tǒng)到物理磁盤分區(qū)的劃分很相似。正如無法確定 區(qū)域的具體位置，我們也 不知道一個Unix 文件系統(tǒng)中的目錄位于哪個

磁盤分區(qū)。

一旦一個區(qū)域的授權機構被委派后，由它負責向該區(qū)域提供多個名字服務器。當一個新 系統(tǒng)加入到一個區(qū)域中時，該區(qū)域的DNS 管理者為該新系統(tǒng)申請一個域名和一個IP 地址，并 將它們加到名字服務器的數(shù)據庫中。這就是授權機構存在的必要性。例如，在一個小規(guī)模的 大學，一個人就能完成每次新系統(tǒng)的加入。但對一個規(guī)模較大的大學來說，這一工作必須被 專門委派的機構（可能是系）來完成，因為一個人

已無法維持這一工作。

一個名字服務器負責一個或多個區(qū)域。一個區(qū)域的管理者必須為該區(qū)域提供一個主名字 服務器和至少一個輔助名字服務器。主、輔名字服務器必須是獨立和冗余的，以便當某個名 字服務器發(fā)生故障時不會

影響該區(qū)域的名字服務。

主、輔名字服務器的主要區(qū)別在于主名字服務器從磁盤文件中調入該區(qū)域的所有信息， 而輔名字服務器則從主服務器調入所有信息。我們將輔名字服務器從主服務器調入信息稱為 區(qū)域傳送。 當一個新主機加入一個區(qū)域時，區(qū)域管理者將適當?shù)男畔ⅲㄗ钌侔趾虸P 地址）加 入到運行在主名字服務器上的一個磁盤文件中，然后通知主名字服務器重新調入它的配置文 件。輔名字服務器定時（通常是每隔3小時）向主名字服務器詢問是否有新數(shù)據。如果有新數(shù) 據，則通過區(qū)域傳送方式獲得新數(shù)據。不要扯遠了，我們接著說zone, 對于BIND （世界上最常用的DNS 程序），一個zone 就對應著一個

/etc/namedb目錄下的文件

比如localhost 的zone 文件 localhost

1|$TTL 3600

2|@ IN SOA strider.diverge.org. hostmaster.diverge.org. (

3| 1 ; Serial

本文所有信息為中興通訊股份有限公司內部信息，未經允許，不得外傳 第4頁，共7頁

內部公開▲

4| 8H ; Refresh

5| 2H ; Retry

6| 1W ; Expire

7| 1D) ; Minimum TTL

8| IN NS localhost.

9|localhost. IN A 127.0.0.1

10| IN AAAA ::1

我們作DNS 查詢時的信息，就是從Zone 文件里取得的

附：幾個有名的DNS 程序 BIND (Berkeley Internet Name Domain)

(這個網站大家應該都知道吧，很多root server就是他們架設的，北京就有）

DJBDNS (Dan J Bernstein's DNS implementation)

MaraDNS

NSD (Name Server Daemon)

PowerDNS

(這個也和有名，相信很多人還用這他們的免費的DNS 服務吧）

TinyDNS （近來也很流行的開源DNS 軟件）

Root Server

當一個名字服務器沒有請求的信息時，它將如何處理？它必須與其他的名字服務器聯(lián)系。 （這正是DNS 的分布特性）。然而，并不是每個名字服務器都知道如何同其他名字服務器聯(lián)系。 相反，每個名字服務器必須知道如何同根的名字服務器聯(lián)系。1993年4月時有8個根名字服務 器，所有的主名字服務器都必須知道根服務器的IP 地址（這些I P地址在主名字服務器的配置 文件中，主服務器必須知道根服務器的IP 地址，而不是它們的域名）。根服務器則知道所有二 級域中的每個授權名字服務器的名字和位置（即IP 地址）。這意味著這樣一個反復的過程：正 在處理請求的名字服務器與根服務器聯(lián)系，根服務器告訴它與

另一個名字服務器聯(lián)系。

本文所有信息為中興通訊股份有限公司內部信息，未經允許，不得外傳 第5頁，共7頁

內部公開▲

你可以通過匿名的F T P獲取當前的根服務器清單。具體是從ftp.rs.internic.net （在/domain這個目

錄下） 或nic.ddn.mil 獲取文件netinfo/root-servers.txt。

比如我國的頂級域名CN 的根服務器

是 CN. NS NS.CNC.AC.CN. CN. NS DNS2.CNNIC.NET.CN. CN. NS NS.CERNET.NET. CN. NS DNS3.CNNIC.NET.CN. CN. NS DNS4.CNNIC.NET.CN. CN. NS DNS5.CNNIC.NET.CN. COM的根服務器是 COM. NS A.GTLD-SERVERS.NET. COM. NS G.GTLD-SERVERS.NET. COM. NS H.GTLD-SERVERS.NET. COM. NS C.GTLD-SERVERS.NET. COM. NS I.GTLD-SERVERS.NET. COM. NS B.GTLD-SERVERS.NET. COM. NS D.GTLD-SERVERS.NET. COM. NS L.GTLD-SERVERS.NET. COM. NS F.GTLD-SERVERS.NET. COM. NS J.GTLD-SERVERS.NET. COM. NS K.GTLD-SERVERS.NET. COM. NS E

.GTLD-SERVERS.NET. COM. NS M.GTLD-SERVERS.NET.

DNS 的一個基本特性是使用超高速緩存。即當一個名字服務器收到有關映射的信息（主 機名字到IP 地址）時，它會將該信息存放在高速緩存中。這樣若以后遇到相同的映射請求， 就能直接使用緩存中的結

果而無需通過其他服務器查詢。

資源記錄RR

A 一個A 記錄定義了一個IP 地址，它存儲32bit 的二進制數(shù)。 PTR 指針記錄用于指針查詢。IP 地址被看作是in-addr.arpa 域下的一個域名（標識符串）。 CNAME 這表示“規(guī)范名字(canonical name)”。它用來表示一個域名（標識符串），而 有規(guī)范名字的域名通常被稱為別名(alias)。某些FTP 服務器使用它向其他的系統(tǒng)提供一個易于記憶的別名。 例如，gated 服務器可通過匿名FTP 從gated.cornell.edu 獲得，但這里并沒有叫做gated 的系統(tǒng)，這僅是為其他系統(tǒng)提供的別名。其他 系統(tǒng)的規(guī)范名為gated.cornell.edu 。

HINFO 表示主機信息：包括說明主機CPU 和操作系統(tǒng)的兩個字符串。并非所有的站 點均提供它們

系統(tǒng)的HINFO 記錄，并且提供的信息也可能不是最新的。

MX 郵件交換記錄，用于以下一些場合： （1）一個沒有連到Internet 的站點能將一個連到Internet 的站點作為它的郵件交換器。這兩個站點能夠用一種交替的方式交 換到達的郵件，而通常使用的協(xié)議是UUCP 協(xié)議。 （2）MX 記錄提供了一種將無法到達其目的主機的郵件傳送到一個替代主機的方式。 （3M X記錄允許機構提供供他人發(fā)送郵件的虛擬主機，如c s . u n i v e r s i t y . e d u，即使這樣的主機 名根

本不存在。 （4）防火墻網關能使用MX 記錄來限制外界與內部系統(tǒng)的連接。

許多不能與Internet 連接的站點通過UUCP 鏈路與一個連接在Internet 上的站點 如UUNET 相連接通過MX 記錄能使用user@host這種郵件地址向那個站點發(fā)送電子郵件。例如，一個假想的域foo.com 可

能有下面的MX 記錄： foo.com MX relay1.UU.NET foo.com MX relay2.UU.NET

MX 記錄能被連接在互聯(lián)網主機中的郵件處理器使用。在這個例子中，其他的 郵件處理器則被告知“如

果有郵件要發(fā)往user@foo.com，就將郵件送到 relay1.uu.net或relay2.uu.net ?！?/p>

每個MX 記錄被賦于一個16bit 的整數(shù)值，該值稱為優(yōu)先值。如果一個目的主 機有多個MX 記錄，它

們按優(yōu)先值由小到大的順序使用。

另一個MX 記錄的例子是處理主機脫機工作或不可達的情況。郵件處理器僅在 無法使用TCP 與目的

主機連接時才使用MX 記錄。

本文所有信息為中興通訊股份有限公司內部信息，未經允許，不得外傳 第6頁，共7頁

內部公開▲ NS 名字服務器記錄。它說明一個域的授權名字服務器。它由域名表示（符號串）

SOA Start of Authority. 定義zone 的名稱, 聯(lián)系e-mail 和刷新時間等等

授權

每個domain 都可因實際需求再細分成許多 sub domain. 上層的 domain 可以將其分出的某

個 sub domain 的 domain name 與 IP mapping 交由另一部機器管理,

這個動作稱之為 delegation（授權）

當我要搜尋 g1.cs.tsinghua.edu.cn 主機時，就需要向管理 .cs.tsinghua.edu.cn 這個網域的那部機器

查詢才行，而要查詢 .cs.tsinghua.edu.cn

則需要在 .tsinghua.edu.cn 上面詢問才可以！這是因為上層DNS 主機 .tsinghua.edu.cn 已經

將 .cs.tsinghua.edu.cn 這個網域的管理權 "授權" 給

ns1.cs.tsinghua.edu.cn 這部機器，當有人要查詢 .cs.tsinghua.edu.cn 這個網域的主機IP

時， .tsinghua.edu.cn 將會把查詢的任務直接轉給

ns1.cs.tsinghua.edu.cn 去管理了！從此， .tsinghua.edu.cn 這個網域的管理主機，將不會再接

管 cs.tsinghua.edu.cn 這個網域的名稱管理

我們有時候用nslookup 查詢一個A 記錄時，DNS 通常返回

Non-authoritative answer: Name: www.im286.com Address: 61.152.251.211

這多半是因為 A記錄在Cache 中的緣故

本文所有信息為中興通訊股份有限公司內部信息，未經允許，不得外傳 第7頁，共7頁