從理論到實踐，全方位認識DNS（實踐篇）
在理論篇我們基本瞭解了DNS的整個協議原理，但是可能還會有著下面的疑問：
- 為什麼我想申請的域名都沒了？
- DNS 域名還要備案，這是為什麼啊？
- 如何將剛申請的域名繫結到自己的網站呢？
- 怎麼才能看到那些在背後默默給我解析的域名伺服器呢？
- 他們說用一個什麼檔案就可以訪問好多好多
不存在的網站，是真的嗎？ - 可信任的域名伺服器是怎麼一回事，難道有些域名伺服器會做壞事？
- 怎麼知道我現在用的域名伺服器有沒有使壞呢？
- ……
我不準備一個一個地去回答這些問題，不過相信我，讀完本文，對於上面問題的答案你會有一個清晰的認識，並且可以解決其他各種各樣關於 DNS 方面的問題。
域名註冊、繫結
首先明確一點，每個人都可以去註冊域名。大多數時候我們希望去註冊一個頂級域名（比如selfboot.cn, google.com等），那些二級域名畢竟不夠好記（比如github託管部落格的域名：username.github.io）。有的頂級域名（比如.tk域名）提供免費的一年域名試用，不過絕大多時候還是要為自己的域名付費的（一般是按年付費，也不是很貴）。要想去註冊域名，首先得找到域名註冊商，國內的比較著名的有DNSpod等，國外的有godaddy等。相信註冊過域名的人都知道絕大多數我們能想到的自己喜歡的域名都已名花有主了，只剩那些不是那麼惹人關注的域名供我們選擇。所以，註冊域名時，發現自己每想到一個域名都顯示被人註冊後，那太正常不過了，說明你的品味比較正常。
這裡一點個人建議，選中一個域名後不要輕易去改了，因為換域名成本挺高的（我猜現在就算給淘寶一千萬，它也不會換另成一個域名吧）。所以，最好不要去用免費的域名，因為指不定啥時候就不讓你用了。你應該相信這麼一個觀點：天下沒有免費的午餐。拓展一下就是，掏錢買服務，心裡踏實。
接下來你可能會希望將自己的站點或者部落格掛在自己選中的域名下，這其實很簡單，只需要找到一個提供域名解析的服務商，然後填寫相應的域名解析記錄。大多時候，你註冊域名的服務商都會免費提供域名解析服務。
現實中，大部分人可能會擁有個人部落格，以前我們都是依賴一個部落格平臺（如CSDN），或者是買一臺VPS託管自己的部落格。不過自從Github推出了Blog服務，好多程式設計師都轉而將部落格託管在上面。Github Blog支援繫結個人域名，並提供了詳細的繫結文件：
域名解析記錄
現在當我們訪問 selfboot.cn 時，DNSpod就會將請求解析到 Github 提供的 IP 地址上。之後 Github 上面的部落格託管伺服器在所有使用者的 CNAME 記錄中，找到本次請求的域名對應的部落格專案地址，比如說是 xuelangZF.github.io，然後返回部落格內容。
域名解析
我們都知道一個域名的解析過程中，可能會有多臺域名伺服器給我們幫助，那麼我們怎麼能看到這些背後的功臣呢？先介紹兩個常用的關於DNS的命令。
dig, nslookup
dig(Domain Information Groper), 是 UNIX/BSD 系統自帶的 DNS 診斷工具，使用十分靈活、方便。
查詢 selfboot.cn 的A記錄，並返回簡短的結果：
1
2
3
|
$ dig selfboot.cn -t A +short
192.30.252.153
192.30.252.154
|
用 dig 還可以查詢某一 ip 對應的域名，如下：
1
2
|
$ dig -x 192.30.252.153 +short
pages.github.com.
|
這裡返回的是pages.github.com，因為當你訪問部落格地址 selfboot.cn 時，其實是Github的pages 伺服器（域名是：pages.github.com）在後臺返回該部落格內容的（根據 CNAME 確定返回哪個部落格）。
nslookup 也是一個 DNS 診斷工具，幾乎所有平臺都自帶該工具，使用也很簡答，可以用 man 查詢手冊。
解析路徑查詢
接下來用 dig 命令檢視從根域名到指定域名中間可能經過的所有域名伺服器，使用 +trace 選項即可。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
dig selfboot.cn +trace @8.8.8.8
; <<>> DiG 9.8.3-P1 <<>> selfboot.cn +trace @8.8.8.8
;; global options: +cmd
. 474418 IN NS j.root-servers.net.
. 474418 IN NS g.root-servers.net.
......
. 474418 IN NS l.root-servers.net.
. 474418 IN NS m.root-servers.net.
;; Received 496 bytes from 8.8.8.8
#53(8.8.8.8) in 12 ms
cn. 172800 IN NS a.dns.cn.
......
cn. 172800 IN NS e.dns.cn.
cn. 172800 IN NS ns.cernet.net.
;; Received 292 bytes from 2001:500:1::803f:235
#53(2001:500:1::803f:235) in 382 ms
selfboot.cn. 86400 IN NS f1g1ns2.dnspod.net.
selfboot.cn. 86400 IN NS f1g1ns1.dnspod.net.
;; Received 83 bytes from 203.119.25.1
#53(203.119.25.1) in 816 ms
selfboot.cn. 14400 IN A 192.30.252.153
selfboot.cn. 14400 IN A 192.30.252.154
selfboot.cn. 600 IN NS f1g1ns1.dnspod.net.
selfboot.cn. 600 IN NS f1g1ns2.dnspod.net.
;; Received 125 bytes from 115.236.137.40
#53(115.236.137.40) in 31 ms
|
可以看到最開始是13臺頂級域名伺服器的NS記錄（中間省去一些記錄減少行數，方便觀察更清楚），接下來是頂級域名 cn. 的權威域名伺服器（省略一些輸出），然後是 selfboot.cn 的 NS 記錄，即 DNSpod 的兩條 NS 記錄，最後從 f1g1ns2.dnspod.net 找到 selfboot.cn 的 A 記錄。
seveas 提供了一個視覺化的路徑查詢工具：dnsgraph，可以線上繪製跟域名到指定域名的所有可能路徑。
當然，實際查詢過程中，大多時候我們在本地快取或者本地域名伺服器快取就能直接找到需要的域名記錄，不需要每次都向根域名伺服器發起請求，然後重複迭代或者遞迴查詢過程。
DNS 缺陷
域名系統設計的很理想很美好，然而仍有一些小的瑕疵，可能會給我們帶來些許困擾。
域名搶注
首先，有些域名對註冊人沒有限制，而另外一些域名則對誰可以得到一個域名空間中的名字有限制。比如pro域名是分配給合適的專業人員，但問題是誰才是專業的呢？顯然醫生、工程師是專業人員，但理髮師、管道工呢？
此外，域名也可以被倒賣。黃牛們會批量註冊大量域名（據說com域名下幾乎每一個普通詞都被人嘗試註冊了域名），然後轉身就以高價轉賣給那些對該域名感興趣的人，這就是所謂的域名搶注。所以，現在你想註冊一個符合自己網站特點的域名是很難的。
這個問題其實還不算嚴重，更要命的是下面兩個問題。
DNS 劫持
我們知道一個域名伺服器對其區域內的使用者解析請求負責，但是並沒有一個機制去監督它有沒有真地負責。也就是說域名伺服器的權力並沒有被關在籠子裡，所以它既可以認真地“為人民服務”，也可以指鹿為馬。於是有些流氓的域名伺服器故意更改一些域名的解析結果，將使用者引向一個錯誤的目標地址。這就叫作 DNS 劫持，主要用來阻止使用者訪問某些特定的網站，或者是將使用者引導到廣告頁面。
DNS 劫持
下面驗證下我所用的域名伺服器有沒有幹這種壞事，只需要一條簡單的命令即可：
1
2
3
4
5
6
7
|
➜ ~ nslookup google.com
Server: 10.8.4.4
Address: 10.8.4.4
#53
Non-authoritative answer:
Name: google.com
Address: 120.196.0.5
|
我的DNS伺服器地址為10.8.4.4，他告訴我google.com的地址是120.196.0.5，我才不信呢。於是用whois 120.196.0.5一看，果真不是Google的地址。針對DNS劫持，我們可以簡單地更換域名伺服器，比較靠譜的一個是Google提供的8.8.8.8。下面用 8.8.8.8 來解析一下 www.google.com 就能看到正確的地址了。
1
2
3
4
5
6
7
|
$ nslookup www.google.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8
#53
Non-authoritative answer:
Name: www.google.com
Address: 216.58.221.68
|
DNS 欺騙
DNS 劫持通過簡單的切換域名伺服器就可以繞過，不過一旦你遇上了 DNS 欺騙，就無法簡單地繞過了。下面我們用不同的域名伺服器來檢視 fb 的 IP 地址，結果都返回了同一個地址，看起來好像是真的一樣，不過也僅僅是看起來而已。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
$ nslookup facebook.com
Server: 10.8.4.4
Address: 10.8.4.4
#53
Non-authoritative answer:
Name: facebook.com
Address: 159.106.121.75
$ nslookup facebook.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8
#53
Non-authoritative answer:
Name: facebook.com
Address: 159.106.121.75
|
這個地址並不是 fb 的伺服器地址（可以在 ViewDNS 查詢所有域名真實的域名資源記錄，ViewDNS是個很好玩的網站，裡面有許多有意思的工具）。其實我Google了一下這個地址，竟然發現了一篇不錯的譯文，看來這個地址早在 2011 年就有了特殊的含義（英文原文是相關閱讀第一個）。
DNS 欺騙簡單來說就是用一個假的 DNS 應答來欺騙使用者計算機，讓其相信這個假的地址，並且拋棄真正的 DNS 應答。在一臺主機發出 DNS 請求後，它就開始等待應答，如果此時有一個看起來正確（擁有和DNS請求一樣的序列號）的應答包，它就會信以為真，並且丟棄稍晚一點到達的應答。
DNS欺騙原理
實施 DNS 欺騙的關鍵在於偽造一個有特定序列號的應答包，並且讓其搶先一步到達發起請求的主機。這對於個人來說還有點難度，但是對於擁有骨幹網節點的組織來說，實在是易如反掌，所以這麼多網站都已淪陷。不過使用網上流傳的那些 hosts檔案，就可以在本機快取許多網站的ip地址，進而可以和部分網站通訊。但是通過hosts檔案並不能完全 Cross the Great FireWall，因為人家還有很多其他手段。
更多閱讀
DNS cache poisoning
DNS Spoofing vs DNS Cache Poisoning
Reset the DNS cache in OS X
人為網路故障
DNS欺騙原理及工作工程分析
DNS汙染與劫持之個人小見
本文轉載自Just For Fun